add a msys2-runtime-3.3 package#96
Conversation
6503211 to
c7a6d01
Compare
dscho
left a comment
There was a problem hiding this comment.
These changes look pretty good so far, thank you so much for working on this @rimrul!
I allowed myself to add a commit to trigger i686 builds for PRs containing the needle msys2-runtime-3.3 in their title, as this here PR does. I hope to get an artifact that I can then test.
8854cec to
e1b4ce5
Compare
|
@rimrul from my side, I consider this one done (modulo the final interactive rebase). Anything else you want to see before flipping this to "ready-for review"? |
These Batch files hail from over 8 years ago, from ae83bac (msys2-runtime: New mount table sorting (WIP), 2014-09-21) to be precise. In all that time, there has not been a hint that they had been useful. So let's drop them. Signed-off-by: Johannes Schindelin <[email protected]>
…atibility We plan to update the main `msys2-runtime` package to 3.4.x before Git for Windows v2.41.0, [1] but Cygwin 3.4.x only supports AMD64 [2]. Create a separate Package for Version 3.3 of the runtime like MSys2 [3] to allow us to provide x86 releases according to our x86 deprecation timeline [1]. [1] git-for-windows/git#4279 [2] https://github.com/cygwin/cygwin/blob/HEAD/winsup/cygwin/release/3.4.0#L6 [3] msys2#3379 Signed-off-by: Matthias Aßhauer <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
|
I guess technically we do not need the x86_64 builds, but what's the harm, eh? 😁 |
|
Yes, that should be fine. |
|
I think the next step should be a PR in |
So now I know what the harm is: https://github.com/git-for-windows/git-sdk-64/actions/runs/4921830149/jobs/8792046619 says this: Same problem in the This suggests to me that the I fear that we'll have to |
|
Hmm. MSYS2 does not seem to have any problems with this package name! See https://packages.msys2.org/package/msys2-runtime-3.3-devel?repo=msys&variant=x86_64 Also: $ tar tvf /var/lib/pacman/sync/msys.db | grep msys2-runtime
drwxr-xr-x repo/repo 0 2023-04-02 10:39 msys2-runtime-3.3-3.3.6-5/
-rw-r--r-- repo/repo 1514 2023-04-02 10:39 msys2-runtime-3.3-3.3.6-5/desc
drwxr-xr-x repo/repo 0 2023-04-02 10:39 msys2-runtime-3.3-devel-3.3.6-5/
-rw-r--r-- repo/repo 1562 2023-04-02 10:39 msys2-runtime-3.3-devel-3.3.6-5/desc
drwxr-xr-x repo/repo 0 2023-04-02 10:39 msys2-runtime-3.4.6-2/
-rw-r--r-- repo/repo 1491 2023-04-02 10:39 msys2-runtime-3.4.6-2/desc
drwxr-xr-x repo/repo 0 2023-04-02 10:39 msys2-runtime-devel-3.4.6-2/
-rw-r--r-- repo/repo 1534 2023-04-02 10:39 msys2-runtime-devel-3.4.6-2/descSo the problem must lie with Git for Windows' tooling... I suspect |
Indeed, it looks that way. I consistently used the pattern Gotta fix that in All The Places. And then fix Git for Windows' Pacman databases... |
See git-for-windows/build-extra#499 for that fix.
Done in https://github.com/git-for-windows/git-for-windows-automation/actions/runs/4930413416/jobs/8811298893. The |
The first step of phase 2 of the current timeline(git-for-windows/git#4279 (comment))