[Bug releng/31703] New: Git detection false positive when 'which' not available

[Bug releng/31703] New: Git detection false positive when 'which' not available

[thaines.astro at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31703

            Bug ID: 31703
           Summary: Git detection false positive when 'which' not
                    available
           Product: systemtap
           Version: unspecified
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: releng
          Assignee: systemtap at sourceware dot org
          Reporter: thaines.astro at gmail dot com
  Target Milestone: ---

The fedora containers don't have 'which' installed by default:

  $ docker run --rm fedora:39 which
  docker: Error response from daemon:
    failed to create task for container:
    failed to create shim task:
    OCI runtime create failed:
    runc create failed:
    unable to start container process: exec: "which":
    executable file not found in $PATH: unknown.

The check in git_version.sh notices the failure, but doesn't exit early.

git_found=yes
if [ "x$GIT" = "xgit" ] && [ x`which $GIT 2>/dev/null` = "x" ]; then
    git_found="'$GIT' not found"
    break
fi

I _think_ the solution here is to 'exit' instead of 'break'. Thoughts?

Thanks.
- Tim

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug releng/31703] Git detection false positive when 'which' not available

[sam at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31703

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

--- Comment #1 from Sam James <sam at gentoo dot org> ---
It should really use command -v instead too :)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug releng/31703] Git detection false positive when 'which' not available

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31703

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fche at redhat dot com

--- Comment #2 from Frank Ch. Eigler <fche at redhat dot com> ---
I'm tempted not to diverge unnecessarily from upstream versions
of git_version.sh just because of a buildroot nit like this one.
(One can't expect to build systemtap with a minimal fedora container.)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug releng/31703] Git detection false positive when 'which' not available

[thaines.astro at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31703

--- Comment #3 from Tim Haines <thaines.astro at gmail dot com> ---
It wasn't a completely minimal container. I was just showing that there is no
'which' installed by default. My actual workflow is

  $ docker run -it fedora:39

  yum install -y binutils-devel boost-devel clang cmake libdwarf-devel
elfutils-devel gcc g++ git glibc-static libomp libstdc++-static tbb-devel git
python3 json-c-devel m4 autoconf dh-autoreconf gettext
  /* install Dyninst */
  git clone --depth=1 https://sourceware.org/git/systemtap.git
  cd systemtap
  autoreconf
  mkdir build
  cd build
  ../configure --with-dyninst --without-python3-probes
  make -j2

which gives the surprising error

    In file included from ../session.cxx:25:
    ../session.cxx: In member function ‘std::string
systemtap_session::version_string()’:
    ../version.h:10:66: error: ‘GIT_PRETTY_REV’ was not declared in this scope
       10 |   (STAP_EXTRA_VERSION[0] ? GIT_MESSAGE ", " STAP_EXTRA_VERSION :
GIT_PRETTY_REV)
          |                                                                 
^~~~~~~~~~~~~~
    ../session.cxx:503:62: note: in expansion of macro ‘STAP_EXTENDED_VERSION’
      503 |   return string (VERSION) + "/" + elfutils_version2 + ", " +
STAP_EXTENDED_VERSION;
          |                                                             
^~~~~~~~~~~~~~~~~~~~~

The cause here is that git_version.sh generates an inconsistent state in
'git_version.h'.

  /* whether this is a dist tarball or not */
  #undef GIT_IS_DIST

  /* No errors occured while running git */
  #undef GIT_ERRORS

  /* git utilities not found */
  #define GIT_NOT_FOUND "'git' not found"
  #undef GIT_VERSION

  /* git repo found */
  #define GIT_REPO 1

which causes the error in version.h because GIT_REPO is defined, but
GIT_PRETTY_REV isn't despite the thorough error checking in git_version.sh.
It's just that the first error check "failed successfully". The fix for my
workflow is just to install 'which', but getting to that information was not
driven by error messages.

To be certain, I am sure the overwhelming majority of systemtap users aren't
using it through a container. I ran into this problem in a CI workflow where
from-scratch containers are being used.

For my future reference, do folks prefer seeing the full root-cause analysis in
bug reports? I was trying to keep it succinct.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug releng/31703] Git detection false positive when 'which' not available

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31703

--- Comment #4 from Frank Ch. Eigler <fche at redhat dot com> ---
Full RCA in a bugzilla is godsend, thanks.

It seems like installing

# dnf build-dep systemtap.spec
# dnf -y install rpm-build

is also not enough to will /usr/bin/which into existence, sigh.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug releng/31703] Git detection false positive when 'which' not available

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31703

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #5 from Frank Ch. Eigler <fche at redhat dot com> ---
commit f66e74de9f05

-- 
You are receiving this mail because:
You are the assignee for the bug.