Reinstate `mingw-w64-git`, synchronizing the package definition from Git for Windows

[dscho]

Ever since I moved Git for Windows from MSys to MSYS2 in 2015, I have dreamed of this: To share the identical package definition of mingw-w64-git with MSYS2. This will allow MSYS2 users to benefit from Git for Windows within their regular MSYS2 setup, while allowing existing Git for Windows users to continue using the official installer to install and upgrade.

This here PR is a vital part of the initiative laid out in https://github.com/msys2/MINGW-packages/discussions/16383.

[dscho]

@ognevny I notice that the CLANGARM64 job does not build any packages. Is there any trick to this?

[ognevny]

@ognevny I notice that the CLANGARM64 job does not build any packages. Is there any trick to this?

I've put a suggestion in proper place. there was a missing field

[ognevny]

1. by the way there was a compiler error about using 32-bit time. why is this important for GfW?
2. git history seems not clean after rebase...

[dscho]

• wasi-libc: update to 0+503+ac020b86
• zed: update to 0.213.3
• openexr: update to 3.4.4

Whoops. Will of course drop them when cleaning up this PR branch.

[dscho]

1. by the way there was a compiler error about using 32-bit time. why is this important for GfW?

You mean this:

D:/M/msys64/ucrt64/include/corecrt.h:128:2: error: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64
    128 | #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64
        |  ^~~~~

Wow, that required some digging. That _USE_32BIT_TIME_T stems from https://github.com/git-for-windows/git/commit/fa93bb20d72edf9f7635c63d46101edb206d3d6f, i.e. way before we switched from MinGW to mingw-64. Let's see whether it is possible to drop this flag.

[rimrul]

Wow, that required some digging. That _USE_32BIT_TIME_T stems from https://github.com/git-for-windows/git/commit/fa93bb20d72edf9f7635c63d46101edb206d3d6f, i.e. way before we switched from MinGW to mingw-64.

Isn't this only part of the issue that config.mak.uname treats all native envs beside MINGW64 and CLANGARM64 as MINGW32?

[dscho]

Wow, that required some digging. That _USE_32BIT_TIME_T stems from git-for-windows/git@fa93bb2, i.e. way before we switched from MinGW to mingw-64.

Isn't this only part of the issue that config.mak.uname treats all native envs beside MINGW64 and CLANGARM64 as MINGW32?

It totally is. That's the reason for the -large-address-aware problem in UCRT64.

For now, I'd like to get the build green so as to know what has to be done, and then fix git-for-windows/git properly. Unfortunately, those fixes won't be in a tagged version immediately, but with a little bit of "luck", there will be a v2.52.1 anyway, and if I can get the fixes into the code base before that, we're good to go.

[ognevny]

by the way, can we try to enable rust like in https://github.com/msys2/MSYS2-packages/pull/5812? (but with mingw-w64-rust)

[rimrul]

by the way, can we try to enable rust like in https://github.com/msys2/MSYS2-packages/pull/5812? (but with mingw-w64-rust)

Could we keep that as a separate second step? @dscho has mentioned wanting to keep the package definitions somewhat in sync between Msys2 and Git for Windows and we'll need some preparing for a mingw-w64-rust setup with *-win7-windows-gnu targets on the Git for Windows side.

[ognevny]

mingw-w64-rust setup with *-win7-windows-gnu targets on the Git for Windows side.

do you actually need it? I mean win7 target

[dscho]

by the way, can we try to enable rust like in https://github.com/msys2/MSYS2-packages/pull/5812? (but with mingw-w64-rust)

Good idea! Rust won't stay optional forever, Git's planning on making it mandatory by the end of next year.

Maybe we should leave that for a follow-up PR, though. It'll take some work to get the fixes into Git for Windows, and I get the sense, after reading on the Git mailing list about the last-modified issues and about the :(optional) segfault, that Git v2.52.0 might not be the most robust, and there might be a v2.52.1 soon, which would be the perfect opportunity to integrate the fixes which I developed in this PR's context into git-for-windows/git and then into a tagged version.

In other words, Rust isn't my highest priority right now :-)

[ognevny]

no hurries with Rust, just a suggestion

[dscho]

mingw-w64-rust setup with *-win7-windows-gnu targets on the Git for Windows side.

do you actually need it?

Rust will be mandatory in Git soon and yes, we will need to keep supporting Windows 8.1 and I have been led to believe that this Rust toolchain version is the only one that could provide that support.

[rimrul]

mingw-w64-rust setup with *-win7-windows-gnu targets on the Git for Windows side.

do you actually need it? I mean win7 target

Yes. We do intend to keep supporting Windows 8.1 for now, so it's either win7 targets on MINGW32 and MINGW64 (at least in Git for Windows, not necessarily in Msys2) or older rust.

[ognevny]

mingw-w64-rust setup with *-win7-windows-gnu targets on the Git for Windows side.

do you actually need it?

Rust will be mandatory in Git soon and yes, we will need to keep supporting Windows 8.1 and I have been led to believe that this Rust toolchain version is the only one that could provide that support.

in next years older Windows support seems less relevant... I guess there could be issues with maintaining separate target for older systems

edit: and it's only about MINGW{32,64}

[MehdiChinoune]

Could you fix runtime dependencies, include the direct dependencies and remove the unnecessary ones.

I don't think Rust will keep supporting -win7-windows-gnu target. Also, I assume you know that MSYS2 is gradually dropping mingw32 packages.

[ognevny]

I don't think Rust will keep supporting -win7-windows-gnu target.

these targets are marked with tier-3 support, meaning that they're not even guaranteed to build

[dscho]

Git for Windows will have to support 32-bit builds until 2029(!!!).

[ognevny]

just wondering, is it okay to have such files (/cmd and root executables) installed via git-windows-addons package? this will conflict between MSYS2 environments

  @@ -0,0 +1,27 @@
  +/clang64/
  +/clang64/share/
  +/clang64/share/doc/
  +/clang64/share/doc/git-doc/
  +/clang64/share/doc/git-doc/git-bash.adoc
  +/clang64/share/doc/git-doc/git-bash.html
  +/clang64/share/git/
  +/clang64/share/git/builtins.txt
  +/clang64/share/git/compat-bash.exe
  +/clang64/share/git/edit-git-bash.exe
  +/clang64/share/git/git-for-windows.ico
  +/clang64/share/git/git-wrapper.exe
  +/clang64/share/man/
  +/clang64/share/man/man1/
  +/clang64/share/man/man1/git-bash.1.gz
  +/cmd/
  +/cmd/git.exe
  +/cmd/git-gui.exe
  +/cmd/gitk.exe
  +/cmd/git-receive-pack.exe
  +/cmd/git-upload-pack.exe
  +/cmd/scalar.exe
  +/cmd/start-ssh-agent.cmd
  +/cmd/start-ssh-pageant.cmd
  +/cmd/tig.exe
  +/git-bash.exe
  +/git-cmd.exe

(I might miss this point from the discussion)

[dscho]

just wondering, is it okay to have such files (/cmd and root executables) installed via git-windows-addons package? this will conflict between MSYS2 environments

  @@ -0,0 +1,27 @@
  +/clang64/
  +/clang64/share/
  +/clang64/share/doc/
  +/clang64/share/doc/git-doc/
  +/clang64/share/doc/git-doc/git-bash.adoc
  +/clang64/share/doc/git-doc/git-bash.html
  +/clang64/share/git/
  +/clang64/share/git/builtins.txt
  +/clang64/share/git/compat-bash.exe
  +/clang64/share/git/edit-git-bash.exe
  +/clang64/share/git/git-for-windows.ico
  +/clang64/share/git/git-wrapper.exe
  +/clang64/share/man/
  +/clang64/share/man/man1/
  +/clang64/share/man/man1/git-bash.1.gz
  +/cmd/
  +/cmd/git.exe
  +/cmd/git-gui.exe
  +/cmd/gitk.exe
  +/cmd/git-receive-pack.exe
  +/cmd/git-upload-pack.exe
  +/cmd/scalar.exe
  +/cmd/start-ssh-agent.cmd
  +/cmd/start-ssh-pageant.cmd
  +/cmd/tig.exe
  +/git-bash.exe
  +/git-cmd.exe

(I might miss this point from the discussion)

Yes, these will conflict, and intentionally so. The purpose of the git-for-windows-addons package is to ship those files (which are included in Git for Windows) separately so that this conflict "is okay" because users would have one preferred architecture, and that's the one they'd install these shortcuts for.

The idea behind cmd is to have a directory that can be added to the system-wide PATH via which the git executable is available, without having to add MSYS2's various bin directories (which would otherwise lead to complications e.g. because of find.exe, bash.exe and others, which exists both in MSYS2 as well as in Windows' system32 directory, and serve very different use cases).

To be clear: This package is required in Git for Windows, but if it shouldn't be built in MSYS2's context by default, I'd understand and make it opt-in (similar to mingw-w64-git-pdb).

[dscho]

I don't think Rust will keep supporting -win7-windows-gnu target.

these targets are marked with tier-3 support, meaning that they're not even guaranteed to build

I guess that Git making Rust mandatory could be a fine reason for Git for Windows to drop support for Windows 8.1... Thoughts, @rimrul?

[dscho]

I don't think Rust will keep supporting -win7-windows-gnu target.

these targets are marked with tier-3 support, meaning that they're not even guaranteed to build

I guess that Git making Rust mandatory could be a fine reason for Git for Windows to drop support for Windows 8.1... Thoughts, @rimrul?

(According to https://endoflife.date/windows we're almost 3 years past its end of life...)

[Kreijstal]

this is beautiful

[ognevny]

you can also calculate checksum for git repo if commit is set

[dscho]

you can also calculate checksum for git repo if commit is set

I know, but I'd like to update only when a new version is tagged.

[dscho]

main / UCRT64 (pull_request)Failing after 20m

Seems to be a transient network error:

   Total Download Size:    28.60 MiB
  Total Installed Size:  408.90 MiB
  
  :: Proceed with installation? [Y/n] 
  :: Retrieving packages...
  error: failed retrieving file 'mingw-w64-ucrt-x86_64-python-3.12.12-1-any.pkg.tar.zst.sig' from ftp2.osuosl.org : Connection timed out after 10001 milliseconds

The same job succeeds in my fork, on the same commit.

[ognevny]

yeah, sometimes happens. restarted the job

[lazka]

Seems to be a transient network error:

could be https://gitlab.archlinux.org/pacman/pacman/-/issues/274