Re: [lmi] wx 'git checkout f741031e69de73d5' aborting

[Greg Chicares]

On 2019-03-24 00:20, Vadim Zeitlin wrote:
> On Sat, 23 Mar 2019 21:37:32 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> To reproduce on the command line (full output of './install_wx.sh'[0]
> GC> copied as a footnote below):
> 
>  I'm almost certain that I won't be able to reproduce this because I don't
> have the files that Git is complaining about in my working copy.

Selecting one of the sixteen files listed in the footnote, which I
seem most unlikely to have added intentionally:
  samples/aui/minimal_iphone.xcodeproj/project.pbxproj
and searching for it on the web, I find:

https://github.com/wxWidgets/wxWidgets/tree/master/samples/aui/minimal_iphone.xcodeproj

so it's actually in the repository...

> And for me
> the real question is how did they get there?

...but I can't guess how I could have gotten it.

> GC> /opt/lmi/src/lmi[1]$pushd /cache_for_lmi/vcs/wxWidgets
> GC> /cache_for_lmi/vcs/wxWidgets /opt/lmi/src/lmi
> GC> 
> GC> /cache_for_lmi/vcs/wxWidgets[0]$git rev-parse --quiet --verify 
> f741031e69de73d5816cc56e99c9beba3ac820de^{commit}
> GC> f741031e69de73d5816cc56e99c9beba3ac820de
> GC> 
> GC> /cache_for_lmi/vcs/wxWidgets[0]$git log -1 --oneline
> GC> e38866d3a60 (HEAD) Merge branch 'lzma'
> 
>  I think it's too late for this, but I'd expect "git status" to show plenty
> of changes in the working tree at this moment.

Well, now, wait...in order to preserve a pristine gcc-7.3.0 production
environment, I created a separate chroot for gcc-8.2.0, and the reported
issue occurred in that new chroot. Let's try that last command in both,
along with 'git status', also echoing the chroot name just to be sure:

# old gcc-seven chroot

/cache_for_lmi/vcs/wxWidgets[0]$echo $SCHROOT_ALIAS_NAME
lmi-buster
/cache_for_lmi/vcs/wxWidgets[0]$git log -1 --oneline
f741031e69 (HEAD, origin/master, origin/HEAD) Suppress gcc -Wfloat-conversion 
warning in wxFontInfo ctor
/cache_for_lmi/vcs/wxWidgets[0]$git status
HEAD detached at f741031e69
nothing to commit, working tree clean

# new gcc-eight chroot [after running 'git checkout --force']

/cache_for_lmi/vcs/wxWidgets[0]$echo $SCHROOT_ALIAS_NAME 
lmi-buster2
/cache_for_lmi/vcs/wxWidgets[0]$git log -1 --oneline
f741031e69d (HEAD) Suppress gcc -Wfloat-conversion warning in wxFontInfo ctor
/cache_for_lmi/vcs/wxWidgets[0]$git status
HEAD detached at f741031e69d
nothing to commit, working tree clean

The only difference I see (for gcc-seven, then gcc-eight) is:

f741031e69 (HEAD, origin/master, origin/HEAD) Suppress gcc -Wfloat-conversion 
warning in wxFontInfo ctor
f741031e69d (HEAD) Suppress gcc -Wfloat-conversion warning in wxFontInfo ctor

When I created the gcc-eight chroot, I copied the contents of
the host's /srv/cache_for_lmi/ , including its vcs/wxWidgets
subdirectory, as recommended in README.schroot :

# If cached lmi downloads are available elsewhere, copy them now.
# Copying cache_for_lmi/downloads/ is an optional step that merely
# conserves bandwidth. [...]
#   cp --dereference --preserve --recursive \
#     /srv/cache_for_lmi/* /srv/chroot/lmi-buster2/cache_for_lmi/

Repeating the commands above on the host shows that its last commit
appears to be the old 'lzma' one, and its HEAD is detached, but at
a different SHA1:

/srv/cache_for_lmi/vcs/wxWidgets[0]$ls -di /
2 /
/srv/cache_for_lmi/vcs/wxWidgets[0]$git log -1 --oneline
e38866d3a6 Merge branch 'lzma'
/srv/cache_for_lmi/vcs/wxWidgets[0]$git status          
HEAD detached at e38866d3a6
nothing to commit, working tree clean

Perhaps that's the problem. Elsewhere, README.schroot says:

# Duplicate proprietary repository (if available).
# First, copy "blessed" repository (here, 'cp' is sufficient: this
# bare repository has no references that need to be resolved):
cd /opt/lmi
cp --dereference --preserve --recursive /cache_for_lmi/blessed .

but above when I copied the entire /srv/cache_for_lmi/ :

#   cp --dereference --preserve --recursive \
#     /srv/cache_for_lmi/* /srv/chroot/lmi-buster2/cache_for_lmi/

that command used 'cp' on vcs/wxWidgets , which AFAIK can't be
a bare repository because it has a detached HEAD.

> GC> All of that is exactly what I expect, but then:
> GC> 
> GC> /cache_for_lmi/vcs/wxWidgets[0]$git checkout 
> f741031e69de73d5816cc56e99c9beba3ac820de
> GC> error: The following untracked working tree files would be overwritten by 
> checkout:
> GC>         docs/doxygen/images/drawing-addarctopoint.png
> GC> [...snip fourteen similar lines...]
> GC>         tests/html/htmprint.cpp
> GC> Please move or remove them before you switch branches.
> GC> Aborting
> 
>  Neither of the files mentioned above exists in e38866d3a60 commit, which
> is the current one, yet somehow they do exist in your working tree.

As does
    samples/aui/minimal_iphone.xcodeproj/project.pbxproj
mentioned above. I guess these are actual commits that came after
e38866d3a60, but let's check the host and both chroots:

/srv/cache_for_lmi/vcs/wxWidgets[0]$git log -- 
docs/doxygen/images/drawing-addarctopoint.png |wc -l 
0

/cache_for_lmi/vcs/wxWidgets[0]$echo $SCHROOT_ALIAS_NAME
lmi-buster
/cache_for_lmi/vcs/wxWidgets[0]$git log -- 
docs/doxygen/images/drawing-addarctopoint.png |wc -l
28

/cache_for_lmi/vcs/wxWidgets[0]$echo $SCHROOT_ALIAS_NAME
lmi-buster2
/cache_for_lmi/vcs/wxWidgets[0]$git log -- 
docs/doxygen/images/drawing-addarctopoint.png |wc -l
28

I think this means that my host (i.e., /srv) doesn't have these commits
at all, even with 'git log --all':

/srv/cache_for_lmi/vcs/wxWidgets[0]$git log --all -- 
docs/doxygen/images/drawing-addarctopoint.png |wc -l
0

so both chroots must have done a 'git fetch', but I certainly didn't
do that manually, and 'install_wx.sh' shouldn't have done it either:

# Fetch desired commit from remote host if missing.
if ! git rev-parse --quiet --verify "$wx_commit_sha^{commit}" >/dev/null
then
    git fetch origin
fi

> GC> What's the best way to address this? For now, I've edited
> GC> a local copy of 'install_wx.sh' and made this change:
> GC>   s/checkout/checkout --force/
[...]
> GC> With that change, it seems to work:
> 
>  Yes, this is not surprising. The situation in its own is definitely not
> catastrophic, but I just have no idea how have we got into it.
> 
>  Please let me know if you have any inkling of it,
I'm hoping that the information above might help you diagnose the
problem, because I can't really understand it myself.