From: <rsbecker@nexbridge.com>
To: "'Patrick Steinhardt'" <ps@pks.im>
Cc: "'Johannes Sixt'" <j6t@kdbg.org>,
"'Junio C Hamano'" <gitster@pobox.com>, <git@vger.kernel.org>,
"'Todd Zullinger'" <tmz@pobox.com>
Subject: RE: [ANNOUNCE] Git v2.50.0-rc1 - Test Failed
Date: Thu, 5 Jun 2025 16:27:41 -0400 [thread overview]
Message-ID: <014201dbd658$4da75680$e8f60380$@nexbridge.com> (raw)
In-Reply-To: <aEFb0Sjj0Xuu-t7l@pks.im>
On June 5, 2025 4:57 AM, Patrick Steinhardt wrote:
>On Thu, Jun 05, 2025 at 04:09:54AM -0400, rsbecker@nexbridge.com wrote:
>> On June 4, 2025 3:25 PM, Johannes Sixt wrote:
>> >Am 04.06.25 um 17:17 schrieb Junio C Hamano:
>> >> So the build procedure for git-gui (but not gitk) has changed
>> >> rather extensively after we tagged the preview before -rc1?
>> >> Honestly, I would have preferred to see a change with this impact
>> >> go through the regular 'seen' to 'next' to 'master' way before
>> >> -rc0, but that is water under the bridge.
>> >
>> >I don't think we ever had such a cycle for gitk and git-gui. I carry
>> >inofficial branches 'j6t-testing' in my repositories that interested
parties could
>track instead of 'master'.
>> >I would be happy to hear that people actually do use them.
>> >
>> >> I do not spot anything obviously wrong (and it is not expected that
>> >> I would---we wouldn't have this code sent to me in the first place
>> >> if this is something I can immediately notice). git-gui/Makefile
>> >> sets ALL_LIBFILES to $(wildcard lib/*.tcl) and then does
>> >>
>> >> $(SHELL_PATH) generate-tclindex.sh . ./GIT-GUI-BUILD-OPTIONS
>> >> $(ALL_LIBFILES)
>> >>
>> >> So the error message in Becker's message, i.e.
>> >>
>> >>> /usr/coreutils/bin/bash generate-tclindex.sh .
>> >>> ./GIT-GUI-BUILD-OPTIONS
>> >>> usage: generate-tclindex.sh <BUILD_DIR> <BUILD_OPTIONS> <LIBFILE>
>> >>> [<LIBFILE>...]
>> >>> Makefile:200: recipe for target 'lib/tclIndex' failed
>> >>
>> >> suggests that $(wildcard lib/*tcl) expanded to *nothing*, which
>> >> sounds horribly wrong. They are source material and should exist
>> >> in an unmodified checkout or a tarball extract.
>> >
>> >I don't see anything wrong, either. I can easily verify your theory
>> >that the
>> >$(wildcard) produces an empty list by modifying the pattern.
>> >
>> >Randall, would it be possible for you to find out why $(wildcard
>> >lib/*tcl) produces an empty list in your case?
>>
>> I can verify that $(wildcard lib/*tcl) is correctly reporting an empty
list.
>>
>> There are three directories name lib in the 2.50.0-rc1 commit:
>> ./git-gui/lib
>> ./gitweb/static/js/lib
>> ./perl/build/lib
>> None have any files ending in tcl:
>> $ ls git-gui/lib
>> git-gui.ico meson.build tclIndex win32_shortcut.js $ ls
>> gitweb/static/js/lib common-lib.js cookies.js datetime.js $ ls
>> perl/build/lib FromCPAN Git Git.pm
>>
>> If it possible that your workspace has extra stuff that does not exist
>> at the time make is run. Note that I am using gnu Make 4.2.1 with bash to
perform
>the built/test cycle.
>
>Your "git-gui/lib" directory is missing a bunch of files:
>
> $ git ls-tree v2.50.0-rc1:git-gui/lib
> 100644 blob cfa50fca87827f09b2fc93509e0f249cc03ca6cd about.tcl
> 100644 blob 8441e109be32822df003d3ab3a221d742a74a8b7 blame.tcl
> 100644 blob 8b0c4858890f11cf0e3f31536b584e0596f3aba0 branch.tcl
> 100644 blob d06037decc1a44ad0f0c153cd461a22a138f35ea
> branch_checkout.tcl
> 100644 blob ba367d551d217f12cfae3c2f99cd19da58f1226f
> branch_create.tcl
> 100644 blob a5051637bbc2388c4aab14479ded14d2c41df314
> branch_delete.tcl
> 100644 blob 3a2d79a9cc3a1ade90db21721f75266d797c26f0
> branch_rename.tcl
> 100644 blob a98298366763d841d3f88e4478f0afdc6e9a5653 browser.tcl
> 100644 blob 21ea768d8036c0ae2ba6bd430c6c667b5ac30c4f
> checkout_op.tcl
> 100644 blob ebe50bd7d07e8a430096dc8f5813c781839bd0f6
> choose_font.tcl
> 100644 blob d23abedcb36fd93ab3f12694d607bf354d6cf208
> choose_repository.tcl
> 100644 blob 6dae7937d589c174132e9f8b9bd77133e189590f
> choose_rev.tcl
> 100644 blob e21e7d3d0b7924f85c29dad248492e22de0bf39b chord.tcl
> 100644 blob f08506f3834a1ec821390190b920146d83078997 class.tcl
> 100644 blob a570f9cdc6a406ef9482802e16c4489cc9873c2c commit.tcl
> 100644 blob fafafb81f1269c1a1a130f66c335f7d4a6f27bb9 console.tcl
> 100644 blob 85783081e0d887a7c7857f07670847ef1bc0629d
> database.tcl
> 100644 blob abe82992b6529cf49983029d85348df5d27ceaf5 date.tcl
> 100644 blob d657bfec05b49865627f321ab260633f250f71c6 diff.tcl
> 100644 blob d2e0fa60c3ba3f770f525a8d01c66f17826aea75
> encoding.tcl
> 100644 blob 8968a57f33e37584e3589f03918db2cb89db24e9 error.tcl
> 100644 blob 334cfa5a1a59c320e86789ccf4ed3320584a0215 git-gui.ico
> 100644 blob d2ec24bd80e12af37ca0099b8aca0bc471cb180f index.tcl
> 100644 blob a026de954c3d9cbfd03d4dec9a73a74647bf74ba line.tcl
> 100644 blob 5ff76692f5eeeb51bcca0905385f51963d1e6531 logo.tcl
> 100644 blob 664803cf3fd14c496bbf4b87ca4f7e8e87503ba1 merge.tcl
> 100644 blob 8b8c16b1d616b62e5141b4228f1152921bcb86f1
> mergetool.tcl
> 100644 blob 4b9efab774dc97546f41158ba56b19d20291acfb
> meson.build
> 100644 blob e43971bfa3e0084e1a306fc82111895a301f905e option.tcl
> 100644 blob ef77ed7399c5b0cc1bdd06f1471d275ffd0ab3ad remote.tcl
> 100644 blob 480a6b30d0a9c9aa4f667a618b0e852d637432dd
> remote_add.tcl
> 100644 blob 5ba9fcadd17f315a4a47220f91f81ba964d64b08
> remote_branch_delete.tcl
> 100644 blob ef1e55521d7cea10e280f720ad700a4cd4b71d65 search.tcl
> 100644 blob 674a41f5e0c868b70d84202381fec8b5919f962f shortcut.tcl
> 100644 blob 538d61c792defa7a8e19736039fa5a9af630125c
> spellcheck.tcl
> 100644 blob 589ff8f78aba8273651b33005c6f6abd1db2fa27 sshkey.tcl
> 100644 blob d32b14142ff8383bcdfddecd1d435fbea3260a51
> status_bar.tcl
> 100644 blob f43d84e54fba18b5e2ebf5f9dbf28f3f8db8593d themed.tcl
> 100644 blob 413f1a170079e0cec78ecdbd1adb7baeb83406f2 tools.tcl
> 100644 blob c05413ce432d2d37cc2461f1f1a739001c2220f4
> tools_dlg.tcl
> 100644 blob a1a424aab540663957c96a37cd277ae666287051
> transport.tcl
> 100644 blob db91ab84a56d79be6a5497f885a9181f368b9cf2 win32.tcl
> 100644 blob 117923f8860bb8f0f04c1664d8cbe38804a59831
> win32_shortcut.js
>
>It seems like your working tree is somehow broken?
The actual problem is the prior stage, running make test fails on GIT_GUI,
so
make install fails. The lib/*.tcl are removed. The build command I using is:
Bring back the missing files from the commit
$ git restore .
Run the actual build.
$ /usr/coreutils/bin/make V=1 prefix=/usr/local-ssl3.5 CFLAGS="-g -O2
-D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -Winline
-I/usr/local-ssl3.5/include -I/usr/coreutils/include
-I/usr/tandem/xml/T0625L01_AAE/include" LDFLAGS="-D_LARGEFILE64_SOURCE=1
-D_FILE_OFFSET_BITS=64 /usr/coreutils/lib/libz.a -L/usr/local-ssl3.5/lib
-L/usr/coreutils/lib -L/usr/tandem/xml/T0625L01_AAE/lib"
SHELL=/usr/coreutils/bin/bash
The *.tcl files in git-gui/lib are gone after the above command. I noticed a
few things run by the above - this did not happen in 2.49.
/usr/coreutils/bin/make -C git-gui
gitexecdir='/usr/local-ssl3.5/libexec/git-core' all
make[1]: Entering directory
'/home/jenkinsbuild/.jenkins/workspace/Git_Pipeline/git-gui'
GITGUI_VERSION=0.21.GITGUI
/usr/coreutils/bin/bash generate-git-gui.sh "git-gui.sh" "git-gui"
./GIT-GUI-BUILD-OPTIONS ./GIT-VERSION-FILE
/usr/coreutils/bin/bash generate-tclindex.sh . ./GIT-GUI-BUILD-OPTIONS
lib/merge.tcl lib/error.tcl lib/chord.tcl lib/date.tcl lib/encoding.tcl
lib/remote_branch_delete.tcl lib/branch_delete.tcl lib/line.tcl
lib/choose_rev.tcl lib/console.tcl lib/checkout_op.tcl lib/blame.tcl
lib/class.tcl lib/about.tcl lib/choose_repository.tcl lib/diff.tcl
lib/transport.tcl lib/branch_rename.tcl lib/shortcut.tcl lib/search.tcl
lib/win32.tcl lib/status_bar.tcl lib/tools_dlg.tcl lib/tools.tcl
lib/mergetool.tcl lib/option.tcl lib/database.tcl lib/choose_font.tcl
lib/logo.tcl lib/remote.tcl lib/branch.tcl lib/branch_checkout.tcl
lib/index.tcl lib/sshkey.tcl lib/commit.tcl lib/browser.tcl
lib/remote_add.tcl lib/branch_create.tcl lib/spellcheck.tcl lib/themed.tcl
generate-tclindex.sh: line 21: tclsh: command not found
* tclsh failed; using unoptimized loading
It appears the above removes the *.tcl files. That causes the subsequent
failure.
--Randall
next prev parent reply other threads:[~2025-06-05 20:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-03 17:02 [ANNOUNCE] Git v2.50.0-rc1 Junio C Hamano
2025-06-03 22:33 ` [ANNOUNCE] Git v2.50.0-rc1 - Test Failed rsbecker
2025-06-03 22:45 ` rsbecker
2025-06-04 13:51 ` Todd Zullinger
2025-06-04 15:17 ` Junio C Hamano
2025-06-04 19:25 ` Johannes Sixt
2025-06-05 8:09 ` rsbecker
2025-06-05 8:56 ` Patrick Steinhardt
2025-06-05 20:27 ` rsbecker [this message]
2025-06-05 21:11 ` Johannes Sixt
2025-06-05 21:33 ` Junio C Hamano
2025-06-06 5:57 ` [GIT PULL] git-gui: fix for: " Johannes Sixt
2025-07-22 17:45 ` [GIT PULL] git-gui: Sync with 2.50.1, Tcl >= 8.6, git >= 2.36 Johannes Sixt
2025-06-05 21:44 ` [ANNOUNCE] Git v2.50.0-rc1 - Test Failed rsbecker
2025-06-05 22:06 ` Junio C Hamano
2025-06-05 23:38 ` 'Todd Zullinger'
2025-06-06 7:20 ` rsbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='014201dbd658$4da75680$e8f60380$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=ps@pks.im \
--cc=tmz@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).