Re: [lmi] Transient git error

[Greg Chicares]

On 3/22/23 22:43, Vadim Zeitlin wrote:
> On Wed, 22 Mar 2023 21:09:53 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> In a freshly-built chroot, 'git fetch --all' initially failed as
> GC> follows...
> GC> 
> GC> Could not access submodule '3rdparty/wxWidgets' at commit 938b8a6ae
> GC> Could not access submodule '3rdparty/wxpdfdoc' at commit 8752a7da6
> GC> Could not access submodule '3rdparty/xmlwrapp' at commit 8752a7da6
> 
>  I guess it was a bad idea to push my "tt" branch containing these commits,
> which reference my own old submodules (predating the ones under
> third_party) to GitHub. It's convenient for me, but I can live without it
> and delete it from there. Should I do it?

To answer that, first we must ascertain whether any actual
problem exists in practice--i.e., whether any of the libraries
failed to update correctly. This may help:

$ git submodule status
 f507d167f1755b7eaea09fb1a44d29aab828b6d1 third_party/libxml2 
(remotes/origin/lmi-2.10)
 5eca7fb65b7337409a02f9f94fde608edf7d1b0a third_party/libxslt 
(remotes/origin/lmi-1.1.37)
 a812fffda3fe686c94e24bff27e8effd96e4de64 third_party/wx 
(v3.1.6-final-981-ga812fffda3)
 409411199b5410a147581ac7c2d2c4d34d686773 third_party/wxpdfdoc 
(v0.9.8-69-g4094111)
 cdb0e46338c00a04f40a0d0ef1a64ce6925e45da third_party/xmlwrapp 
(v0.9.0-152-gcdb0e46)

I'm pretty sure that libxml2, libxslt, and xmlwrapp have been
updated correctly, because their SHA1s match those in your
three commits that I've cherry-picked. Similarly, wx seems to
be at the SHA1 specified by your commit 92c6118c4eafb8b9a3efb
that I had previously pushed. I haven't gone exploring the
submodules to verify that the source code matches the intended
versions, but I think that's unnecessary because we can rely
with probability (1 - 2^(-sizeof(SHA1))) on the SHA1s.

>  FWIW I think the errors above are not really fatal: these commits are
> "incomplete", as the submodules they reference are not available, but as
> long as you don't try to actually use submodules at this version, it
> doesn't seem to be a problem.

I wouldn't dream of using either of the SHA1s reported in these
"upload-pack: not our ref" messages:

> GC> fatal: remote error: upload-pack: not our ref 
> f279b417f431db35c90a9813d3f2e6abfaeead30
> GC> fatal: remote error: upload-pack: not our ref 
> 9325bced99d79d78658a6c7a620a34f73f4abfa5
> GC> Errors during submodule fetch:
> GC>         third_party/libxslt
> GC>         third_party/libxml2
> GC> error: could not fetch xanadu
> GC> 
> GC> ...but then repeating the same command verbatim succeeded.
> 
>  I'm not sure if it has really succeeded, it's rather that it hasn't failed
> again because it had already given errors about these commits and there
> were no new problematic commits to fetch.

However, AIUI, as a practical matter all I should actually care
about is whether the SHA1s reported by 'git submodule status'
above are as you intend. Aren't we entitled to conclude that
such is the case?

> GC> AFAICT, the problem fixed itself somehow, but naturally I wonder
> GC> how this could be.
> 
>  I believe that the problem is not really fixed, if you do try to use one
> of the commits above, you're going to have problems. But, of course, you
> shouldn't have any reason to try to do it (other than morbid curiosity,
> perhaps).

I'm not as extremely curious as that, so I think we're all set.

You could readily validate this if I were to push these commits,
but I'm not going to do that yet, not until we're ready to create
binary distributions with only wx upgraded. I suppose I could
just push the submodule commits and they'd have no effect until
we actually run a 'git submodule update' command; but that could
occur automatically, due to:
  install_msw.sh:git submodule update "$coefficiency" --recursive --init
and we want to guard against releasing anything we haven't tested.