MSYS2 News

MSYS2 Newshttps://www.msys2.org/news/MSYS2 project news and updatesen-usSun, 05 Apr 2026 10:11:42 +0000Deprecating the MINGW64 Environmenthttps://www.msys2.org/news/#2026-03-15-deprecating-the-mingw64-environmenthttps://www.msys2.org/news/#2026-03-15-deprecating-the-mingw64-environmentSun, 15 Mar 2026 00:00:00 +0000 As support for Windows 8.1 has been dropped, there is no longer a need for non-UCRT environments such as MINGW64. Consequently, we are beginning to phase out the MINGW64 environment. To start, no new packages will be added to this environment, and existing leaf packages may be removed if issues arise. If you are currently relying on the MINGW64 environment, please consider switching to UCRT64 or CLANG64 instead. Native Git Now Available in MSYS2https://www.msys2.org/news/#2026-02-28-native-git-now-available-in-msys2https://www.msys2.org/news/#2026-02-28-native-git-now-available-in-msys2Sat, 28 Feb 2026 00:00:00 +0000 We are pleased to announce that MSYS2 now includes a <a href="https://packages.msys2.org/base/mingw-w64-git">native MinGW build of Git</a> alongside the existing Cygwin-based version. This is made possible thanks to the hard work of the <a href="https://github.com/orgs/git-for-windows/people">'Git for Windows' team</a>, who made various changes in both projects, to make it possible to package their MinGW port of git and easily keep it in sync going forward. If you encounter any issues, please report them to us first before contacting the 'Git for Windows' team. For comparison, some quick and unscientific benchmarks for a local clone of the <a href="https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git">GCC repo</a>: <table> <thead> <tr> <th>Operation</th> <th>Cygwin Git</th> <th>MinGW Git</th> </tr> </thead> <tbody> <tr> <td><code>git status</code></td> <td>~1 s</td> <td>~0.5 s</td> </tr> <tr> <td><code>git switch</code> (gcc 14↔15)</td> <td>~14.0 s</td> <td>~10.0 s</td> </tr> <tr> <td><code>git clone</code> (local)</td> <td>~45 s</td> <td>~22 s</td> </tr> <tr> <td><code>git grep</code></td> <td>~2.6 s</td> <td>~0.55 s</td> </tr> </tbody> </table> If you were using the <a href="https://gitforwindows.org/install-inside-msys2-proper.html">hack to make 'Git for Windows' work in MSYS2</a>, which involves adding 'Git for Windows' repositories to pacman, you might now be able to switch to just installing git from MSYS2's own repositories instead. This also allows you to install native git into environments other than MINGW64, such as UCRT64 or CLANG64. Please note that our package is not as fully integrated with Windows like the Git for Windows installer version, and lacks some features such as the credential manager. It's also not as widely tested yet. Please give it a try and let us know if you encounter any issues or missing features. Dropping support for Windows 8.1https://www.msys2.org/news/#2026-02-28-dropping-support-for-windows-81https://www.msys2.org/news/#2026-02-28-dropping-support-for-windows-81Sat, 28 Feb 2026 00:00:00 +0000 As Windows 8.1 has been end-of-life (EOL) for three years, Firefox has stopped supporting it as of today, and our download statistics show that only <0.05% of our users are on Windows 8.1, we have decided to drop support for Windows 8.1 in MSYS2. This does not mean that things will immediately stop working on Windows 8.1, but we will no longer attempt to resolve issues specific to it. Rust Cygwin packages updatehttps://www.msys2.org/news/#2026-02-01-rust-cygwin-packages-updatehttps://www.msys2.org/news/#2026-02-01-rust-cygwin-packages-updateSun, 01 Feb 2026 00:00:00 +0000 Back in September we got our first Rust-based Cygwin package with fish shell v4, and the number of Rust-based packages has slowly increased since then. We now have the following packages in the repo: breezy, cargo-c, cargo-edit, fish, git, just, maturin, python-cryptography, python-dulwich, python, fastbencode, python-patiencediff, python-uv-build, uutils-coreutils Thank you to everyone in the Rust community who has contributed to, or merged Cygwin support into the relevant crates! More strict "pip install" for local installationshttps://www.msys2.org/news/#2026-01-31-more-strict-pip-install-for-local-installationshttps://www.msys2.org/news/#2026-01-31-more-strict-pip-install-for-local-installationsSat, 31 Jan 2026 00:00:00 +0000 Our mingw pip has for some time now printed a warning if you've used it to install into the user/system site-packages, since it can break/conflict with MSYS2-provided packages. We have now made this check more strict by erroring out instead. This means that if you use "pip install" on your local machine outside of a venv, you must now pass "--break-system-packages" to pip for it to continue. In case you are running in CI then it's still a warning, and there are currently no plans to change that. We check if the "CI" env var is set, which is the case with GitHub and GitLab by default for example. However, it's still a good idea to pass "--break-system-packages" even in CI to silence the warning and inform your future self that this might be a source of problems. Python 3.14 Updatehttps://www.msys2.org/news/#2026-01-31-python-314-updatehttps://www.msys2.org/news/#2026-01-31-python-314-updateSat, 31 Jan 2026 00:00:00 +0000 We've now updated to 3.14, just a few weeks after the 3.13 update. Everything was still fresh in our minds and the rebase turned out to be easy. The rebuild was the smoothest Python rebuild so far, so there is a good chance you wont notice any issues either. However, please tell us if you find any. As announced, we removed the cygpty patch, so if you are on systems without conpty, like Windows 8.1, it will no longer detect a tty in mintty and you'll have to pass "-i" explicitly to get an interactive Python shell. Python 3.13 Updatehttps://www.msys2.org/news/#2026-01-10-python-313-updatehttps://www.msys2.org/news/#2026-01-10-python-313-updateSat, 10 Jan 2026 00:00:00 +0000 We have now updated to Python 3.13. Please let us know if you encounter any issues. Some notable smaller changes: <ul> <li>The <code>_wmi</code> module, which is used by various functions in the <code>platform</code> module, and which was missing from our 3.12 build, is now included.</li> <li>The <code>SOABI</code> sysconfig variable format now matches Unix builds, in that it is a subset of <code>EXT_SUFFIX</code>.</li> <li>Various sysconfig fixes: <code>AR</code> is now a Windows path and <code>prefix</code> is now relocated.</li> <li>The <code>python-config</code> tool is now a Python script instead of a Bash script.</li> <li>We plan to remove the isatty() patch for detecting Cygwin pipes as an interactive terminal with the next update to 3.14. This should only affect Windows 8.1 users or those with conpty disabled.</li> </ul> During the package rebuilds, we encountered an issue due to a behavioral change in Python 3.13: <code>os.path.isabs()</code> now returns False for paths beginning with '/'. This change exposed several dependencies on the previous behavior in build tools. Something to watch out for. Thanks to <a href="https://github.com/Alexpux">@Alexpux</a> for helping with the rebase/update and to everyone who fixed packages during the rebuild. Replacing x86_64-pc-msys with x86_64-pc-cygwinhttps://www.msys2.org/news/#2025-06-20-replacing-x86_64-pc-msys-with-x86_64-pc-cygwinhttps://www.msys2.org/news/#2025-06-20-replacing-x86_64-pc-msys-with-x86_64-pc-cygwinFri, 20 Jun 2025 00:00:00 +0000 As part of our ongoing effort to move MSYS2 closer to Cygwin, we have now replaced the <code>x86_64-pc-msys</code> triplet with <code>x86_64-pc-cygwin</code> as the default host triplet for the MSYS environment. This means: <ul> <li>The <code>$MSYSTEM_CHOST</code> environment variable will now report <code>x86_64-pc-cygwin</code> instead of <code>x86_64-pc-msys</code></li> <li>Autotools based configure scripts will default to <code>x86_64-pc-cygwin</code> instead of <code>x86_64-pc-msys</code></li> <li><code>gcc -dumpmachine</code> will report <code>x86_64-pc-cygwin</code> instead of <code>x86_64-pc-msys</code></li> </ul> Ideally this should not affect most users. If there are any issues with this change, please let us know. Hosted Windows ARM64 Runners on GitHub Actionshttps://www.msys2.org/news/#2025-04-18-hosted-windows-arm64-runners-on-github-actionshttps://www.msys2.org/news/#2025-04-18-hosted-windows-arm64-runners-on-github-actionsFri, 18 Apr 2025 00:00:00 +0000 Earlier this week, GitHub finally <a href="https://github.blog/changelog/2025-04-14-windows-arm64-hosted-runners-now-available-in-public-preview/">added Windows ARM64 runners to GitHub Actions</a>, which is great news and will help us a lot producing native ARM64 packages in MSYS2 in the future. Since many of our packages are already available for ARM64, you might be wondering how we managed to do this until now. Let's take a look back: In early 2021, <a href="https://github.com/jeremyd2019">Jeremy</a> bootstrapped our CLANGARM64 environment from a Cygwin LLVM build and built our first CLANGARM64 packages. To automate our package builds, we needed GitHub Actions support, which Jeremy also took on himself, and set up a WoA machine with an ARM64 version of GitHub runner, which we integrated into msys2-autobuild in late 2021. The whole ecosystem was in a very early stage at the time, such as the Actions runner itself, ARM64 support for Node.js, ARM64 Windows itself, Windows x64 emulation, etc., so things were not easy. Hardware was also an issue, as emulation was very slow, real hardware was very underpowered, and there were no dev kits in the beginning, so the runner had to move hardware several times over its lifetime. Another challenge was that the self-hosted runner builds were not isolated, which meant that we could only use them for final package builds, so as not to expose them to untrusted users. So no CI checks on random PRs or other repos that are exposed in any way. While this meant that ARM64-only issues were sometimes found very late in the process, fortunately there was always someone around to debug things on real hardware if needed. Some stats on the last year of the self-hosted ARM64 runner: <ul> <li>It ran 1835 jobs</li> <li>It built packages for 1593 hours</li> <li>It built 9869 packages</li> <li>It produced 52.4 GB worth of packages</li> </ul> After building for 3-4 years we now have ~93% of all MSYS2 packages available for ARM64. Thanks to <a href="https://github.com/jeremyd2019">Jeremy</a> for maintaining the self-hosted runner for so long, setting it up, updating it, moving it, fixing it, scaling it up for large rebuilds, being very responsive when things got stuck or debugging ARM64-only build issues, and much more. Also thanks to <a href="https://github.com/dennisameling">Dennis Ameling</a> for funding the "QC710 Dev Kit" and <a href="https://github.com/ZacWalk">Zac Walker @ Microsoft</a> for providing us with a "Dev Kit 2023". The future: With the new hosted runners, we can now test with ARM64 in many more places, such as package updates before they are merged, for all our forks of external projects, our GitHub action, our installer, our integration test, and much more. We can also run more jobs in parallel, which will be helpful for large rebuilds like major Python updates. And it allows our community to debug ARM64 related issues even if they do not have ARM64 hardware available, even though debugging in CI is not much fun. For users of our "setup-msys2" GitHub Action this means they can easily add ARM64 testing/building to their project: <div class="highlight"><pre><code>jobs: msys2-clangarm64: runs-on: windows-11-arm steps: - uses: actions/checkout@v4 - uses: msys2/setup-msys2@v2 with: msystem: CLANGARM64 update: true - name: CI-Build shell: msys2 {0} run: | ./ci-build.sh </code></pre></div> Moving MSYS(2) closer to Cygwinhttps://www.msys2.org/news/#2025-02-14-moving-msys2-closer-to-cygwinhttps://www.msys2.org/news/#2025-02-14-moving-msys2-closer-to-cygwinFri, 14 Feb 2025 00:00:00 +0000 In MSYS2, in addition to the native environments such as UCRT64/CLANG64, there is also the "MSYS" environment, which contains mostly Cygwin-based software. Since the start of the MSYS2 project, the Cygwin tools in MSYS have been modified to build for MSYS instead of Cygwin. This means that the languages and tools have been patched to report their platform as "msys", and for the build tools this means that we have our own MSYS specific target triplet (x86_64-pc-msys), and uname reports "MSYS" as well. Whatever the motivation was back then, the reality today is that our Cygwin packages are 99% the same as Cygwin's, with only a few things needing tweaking. The downside of defining our own platform/system/triplet is that every build system has to be patched to treat us as Cygwin-like, which is tedious and error-prone when adding/updating packages, and also divides the community. Another drawback is that it's confusing to users, as the names of MSYS2, the project, and MSYS are too similar, and it's not clear that MSYS mostly just means Cygwin. Some time ago we started to remove these differences by replacing "msys" with "cygwin" + patches where possible. So instead of MSYS being a fork of Cygwin, it would just be a slightly modified/extended variant of Cygwin. The goal is that any software that supports Cygwin should be buildable as is under MSYS2. The first change in this direction already happened some time ago, when CMake would define both CYGWIN and MSYS as true when building under MSYS. Since then, we have tweaked several more things to get closer to that goal: <ul> <li>CMake has reported CYGWIN as true since 2021</li> <li>Meson has reported to be running under Cygwin since we added it in 2018</li> <li>Python has been changed to report "sys.platform" as "cygwin", and recently "sysconfig.get_platform()" has been changed to report "cygwin-x86_64" as well.</li> <li>Perl has recently been changed to report "$^O" as "cygwin" instead of "msys".</li> <li>Bash has recently been changed to report "$OSTYPE" as "cygwin" instead of "msys".</li> <li>Almost all of our packages have been ported to build for the Cygwin triplet, except for the toolchain packages.</li> </ul> The rule of thumb is that where possible, things will continue to identify as both Cygwin and MSYS, for example, CMake will set both MSYS and CYGWIN, C/C++ will define both <code>__MSYS__</code> and <code>__CYGWIN__</code>. Where this is not possible, things will simply identify as Cygwin, or we will have to find workarounds. The next planned steps for this transition are currently: <ul> <li>Change the default host triplet from "x86_64-pc-msys" to "x86_64-pc-cygwin"</li> <li>Change the runtime to be a superset of Cygwin in more places, e.g. make the CYGWIN env var work as a fallback if MSYS is not set. The goal is to make the Cygwin documentation mostly applicable to MSYS2 as well.</li> </ul> For MSYS2 users these changes should be mostly invisible, but if you are a developer targeting the MSYS environment there might be some fallout. Despite that, we hope these changes will lead to better compatibility and easier maintenance in the long run. Let us know if you experience any problems. Server maintenance on 2025-02-15/16https://www.msys2.org/news/#2025-02-13-server-maintenance-on-2025-02-1516https://www.msys2.org/news/#2025-02-13-server-maintenance-on-2025-02-1516Thu, 13 Feb 2025 00:00:00 +0000 There will be a short server maintenance around the weekend of 2025-02-15/16 which will affect repo.msys2.org, mirror.msys2.org, packages.msys2.org, and some subdomain redirects of our website. Update: all done now Removal of the CLANG32 Environmenthttps://www.msys2.org/news/#2024-12-18-removal-of-the-clang32-environmenthttps://www.msys2.org/news/#2024-12-18-removal-of-the-clang32-environmentWed, 18 Dec 2024 00:00:00 +0000 The previously announced removal of the CLANG32 environment is now complete. This concludes the gradual phase-out process that began several months ago. Python 3.12 Updatehttps://www.msys2.org/news/#2024-11-09-python-312-updatehttps://www.msys2.org/news/#2024-11-09-python-312-updateSat, 09 Nov 2024 00:00:00 +0000 Over the last week we finally moved from Python 3.11 to 3.12. Thanks to <a href="https://github.com/naveen521kk">@naveen521kk</a> for updating the fork, and everyone else who helped with rebuild issues. Also thanks to <a href="https://github.com/jeremyd2019">@jeremyd2019</a> for watching the external arm64 runner while it rebuilt all those 940 packages and fixing arm64 related issues. There are some minor things to watch out for with this update: <ul> <li>We've enabled <a href="https://peps.python.org/pep-0668/">PEP 668</a> by marking the system site-packages directory as externally managed. To prevent this from causing too many problems right away <a href="https://github.com/msys2/MINGW-packages/commit/4447a7ba7971d3480e7bd24951ec8e51328d23c9">we have patched our version of pip</a> to only give a warning instead of an error if you install outside of a venv. However, we may change this back to a real error in the future. If this is causing any problems or if there are any concerns with re-enabling the error in the future let us know.</li> <li>While not MSYS2 specific, 3.12 is the version that <a href="https://peps.python.org/pep-0632">dropped the included distutils package</a> and distutils is now only available as part of setuptools. While the current setuptools should handle our Python out of the box, there may be slight differences. Make sure to remove anything setting <code>SETUPTOOLS_USE_DISTUTILS=stdlib</code> as that will lead to distutils import errors.</li> <li>As with every major Python update we had to drop a few packages that were incompatible with the new version and for which no update or patch was available. One notable package there is py2exe which does not support 3.12+ right now and there is also no patch available, see <a href="https://github.com/py2exe/py2exe/issues/191">the upstream issue</a> for details.</li> </ul> Disabling mingw-w64 wildcard support by defaulthttps://www.msys2.org/news/#2024-11-03-disabling-mingw-w64-wildcard-support-by-defaulthttps://www.msys2.org/news/#2024-11-03-disabling-mingw-w64-wildcard-support-by-defaultSun, 03 Nov 2024 00:00:00 +0000 For historical reasons MSYS2 enabled wildcard support in mingw-w64 at build time. This means that every built executable had wildcard support enabled by default, unless it explicitly opted out. Wildcard support in this case means that program arguments containing <code>?</code>and <code>*</code> can be expanded to one or more file paths if the pattern happens to match paths of files on disk. Note that this happens directly in the target program, not in a shell beforehand. This expansion has several problems: <ul> <li>Behave differently than MSVC built executables</li> <li>It's confusing to users when wildcard handling is accidentally triggered. For example, passing a regex as an argument to a CLI tool that starts matching random files, breaking the pattern.</li> <li>It may have security implications if arguments to executables are forwarded from user-controlled input, in which case an argument could expand to a different string depending on the files present on the filesystem.</li> </ul> Given all this, we have decided to disable wildcard handling by default. This means that any package and executable that is built after this change will get the new default behavior. <div class="highlight"><pre><code>$ python -c 'import sys; print(sys.argv)' '*a.txt' # before ['-c', 'a.txt', 'aaaa.txt', 'bla.txt'] $ python -c 'import sys; print(sys.argv)' '*a.txt' # after ['-c', '*a.txt'] </code></pre></div> Our hope/assumption is that this will not affect many users, as most will rely on globbing at a higher level, be it bash, or build systems. If you experience any problems, please let us know. See also <a href="https://www.msys2.org/docs/c/#expanding-wildcard-arguments">the documentation</a> on how to force wildcard handling for your applications even after this change. Starting to drop the CLANG32 environmenthttps://www.msys2.org/news/#2024-09-23-starting-to-drop-the-clang32-environmenthttps://www.msys2.org/news/#2024-09-23-starting-to-drop-the-clang32-environmentMon, 23 Sep 2024 00:00:00 +0000 9 months ago we started to reduce the number of packages for the 32-bit environments. Now we are starting to drop the CLANG32 environment. This means that we will no longer add new packages for this environment and will remove the existing ones over the next months. If this is affecting you, please let us know. While CLANG32 has some unique features in the context of MSYS2, such as being the only environment to use UCRT for 32-bit and the LLVM toolchain, it has seen very little use in our download statistics, and we don't think it's worth supporting any longer. If you are in need for a 32-bit LLVM toolchain, consider using <a href="https://github.com/mstorsjo/llvm-mingw">LLVM MinGW</a> instead. MSYS2 support in setuptools v70.0.2https://www.msys2.org/news/#2024-07-28-msys2-support-in-setuptools-v7002https://www.msys2.org/news/#2024-07-28-msys2-support-in-setuptools-v7002Sun, 28 Jul 2024 00:00:00 +0000 Setuptools v70.0.2 now supports mingw Python and MSYS2 natively. This eliminates the need for SETUPTOOLS_USE_DISTUTILS=stdlib when building C extensions, enabling "pip install" to just work for most packages without extra steps. With the stdlib distutils now no longer being required to build packages we can continue our work to update to Python 3.12. File conflicts when updating pythonhttps://www.msys2.org/news/#2024-07-08-file-conflicts-when-updating-pythonhttps://www.msys2.org/news/#2024-07-08-file-conflicts-when-updating-pythonMon, 08 Jul 2024 00:00:00 +0000 Due to the recent Python 3.12 update missing .pyc files, you might see file conflicts when updating: <div class="highlight"><pre><code>error: failed to commit transaction (conflicting files) python: /usr/lib/python3.12/__pycache__/ast.cpython-312.pyc exists in filesystem python: /usr/lib/python3.12/__pycache__/dis.cpython-312.pyc exists in filesystem python: /usr/lib/python3.12/__pycache__/inspect.cpython-312.pyc exists in filesystem python: /usr/lib/python3.12/__pycache__/opcode.cpython-312.pyc exists in filesystem ... </code></pre></div> This can be fixed by running <div class="highlight"><pre><code>$ pacman --overwrite "/usr/lib/python3.12/*" -Suy </code></pre></div> Sorry for the inconvenience. Server changeshttps://www.msys2.org/news/#2024-06-21-server-changeshttps://www.msys2.org/news/#2024-06-21-server-changesFri, 21 Jun 2024 00:00:00 +0000 Over the past few weeks we've been experiencing various problems with our server, which also led to an extended downtime on 2024-06-12. It turned out that both disks were failing and instead of replacing them both we decided to simply move to a new server. This transition is now complete and everything should be back to normal. <ul> <li>Old IP: <code>178.63.98.68</code></li> <li>New IP: <code>88.99.69.85</code></li> </ul> Many thanks to <a href="https://dakulov.com">Dmitriy Akulov</a> of <a href="https://www.jsdelivr.com/">jsDelivr</a> and <a href="https://www.jsdelivr.com/globalping">Globalping</a> for helping us diagnose the problem and generously providing us with a new server. GCC 14.1https://www.msys2.org/news/#2024-05-10-gcc-141https://www.msys2.org/news/#2024-05-10-gcc-141Fri, 10 May 2024 00:00:00 +0000 We have updated GCC to version 14.1. See the <a href="https://gcc.gnu.org/gcc-14/changes.html">GCC 14.1 release notes</a> for more information. Similar to recent Clang releases, GCC also got stricter and multiple warnings are now errors by default, see the <a href="https://gcc.gnu.org/gcc-14/porting_to.html">GCC 14.1 porting guide</a> for details. To reduce the maintenance burden we have dropped Ada/Objective-C/libgccjit support from the 32-bit/mingw32 variant. Update to Cygwin 3.5 on Unsupported Systemshttps://www.msys2.org/news/#2024-05-03-update-to-cygwin-35-on-unsupported-systemshttps://www.msys2.org/news/#2024-05-03-update-to-cygwin-35-on-unsupported-systemsFri, 03 May 2024 00:00:00 +0000 The update to Cygwin 3.5 means MSYS2 will no longer start on long unsupported systems like Windows 7 and 8.0. To keep MSYS2 running for a bit longer on such systems you can switch to the legacy runtime using: <div class="highlight"><pre><code>$ pacman --noconfirm -Sy msys2-runtime-3.4 msys2-runtime-3.4-devel </code></pre></div> In case you have already updated and can't start MSYS2 anymore, you can use the following steps to downgrade: <ul> <li>Get the <a href="https://github.com/msys2/msys2-installer/releases/download/2024-01-13/msys2-base-x86_64-20240113.sfx.exe">last MSYS2 installer release</a> and extract it</li> <li>Copy the "msys64\usr\bin\msys-2.0.dll" from there to the same location in your existing MSYS2 installation</li> <li>Start a MSYS2 terminal and switch to the legacy runtime using the command above</li> </ul> MSYS2 on Linux (Experimental)https://www.msys2.org/news/#2024-05-02-msys2-on-linux-experimentalhttps://www.msys2.org/news/#2024-05-02-msys2-on-linux-experimentalThu, 02 May 2024 00:00:00 +0000 We've created a Docker image including a Wine fork + Cygwin fixes + MSYS2, as an experiment, so you can run MSYS2 on Linux: <a href="https://github.com/msys2/msys2-docker">https://github.com/msys2/msys2-docker</a> Be warned, it's very slow and flaky, and signature verification is disabled for packages/repos, because otherwise things would be unacceptably slow. Don't use it for anything important. Shout out to <a href="https://github.com/pojntfx">@pojntfx (Felicitas Pojtinger)</a> for the idea and initial Dockerfile and to <a href="https://github.com/jhol">@jhol (Joel Holdsworth)</a> for developing the wine fork. TLS/SSL Support for the Repository Rsync Serverhttps://www.msys2.org/news/#2024-04-23-tlsssl-support-for-the-repository-rsync-serverhttps://www.msys2.org/news/#2024-04-23-tlsssl-support-for-the-repository-rsync-serverTue, 23 Apr 2024 00:00:00 +0000 We have added TLS/SSL support for the repository rsync server. This means that you can now use <div class="highlight"><pre><code>$ rsync-ssl rsync://repo.msys2.org/builds </code></pre></div> to sync the repository over an encrypted connection. Automated Vulnerability Reporting Systemhttps://www.msys2.org/news/#2024-04-02-automated-vulnerability-reporting-systemhttps://www.msys2.org/news/#2024-04-02-automated-vulnerability-reporting-systemTue, 02 Apr 2024 00:00:00 +0000 The <a href="https://packages.msys2.org/security">package index</a> now has some rudimentary support for detecting and displaying <a href="https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures">CVEs</a> and other vulnerability reports for the packages included in MSYS2. We piggyback on existing security scanner tools by using the metadata in the package recipes to create a dummy <a href="https://www.ntia.gov/page/software-bill-materials">SBOM</a> file and then feed the scan results to our website. This gives us some insight into which packages have potential vulnerabilities or which updates should be prioritized. For more information on the process see <a href="https://www.msys2.org/dev/vulnerabilities/">Vulnerability Reporting</a>. Some caveats: <ul> <li>Only about half of our packages have the necessary metadata to be scanned at all. This is mainly because packages that have never had a CVE assigned also don't have a <a href="https://nvd.nist.gov/products/cpe">CPE</a> to link to, and partly because it's just incomplete on our end.</li> <li>The CVE system is currently <a href="https://nvd.nist.gov/general/news/nvd-program-transition-announcement">not fully operational</a>, and for the past few weeks most of the incoming CVEs have not been processed at all. This means that newer CVEs are likely not linked to our packages. Since we use <a href="https://github.com/anchore/grype">grype</a> for scanning we do get some new data from their <a href="https://github.com/anchore/nvd-data-overrides">nvd-data-overrides effort</a> though.</li> <li>Note that we will not try to reduce the number of reported vulnerabilities to zero. We will mainly use them to prioritize updates and be better informed about the security status of our packages.</li> </ul> xz-utils Backdoorhttps://www.msys2.org/news/#2024-03-30-xz-utils-backdoorhttps://www.msys2.org/news/#2024-03-30-xz-utils-backdoorSat, 30 Mar 2024 00:00:00 +0000 In response to the recent <a href="https://en.wikipedia.org/wiki/XZ_Utils_backdoor">xz backdoor</a> we have rebuilt the xz packages for <a href="https://github.com/msys2/MSYS2-packages/pull/4475">msys</a> and <a href="https://github.com/msys2/MINGW-packages/pull/20479">mingw</a> from the git source instead of the tarball, following what <a href="https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commits/main">Arch Linux did</a>. Although we have built and shipped the affected versions, there is no indication at this time that this issue has affected MSYS2 users. Note to the remaining Windows 7 / 8.0 usershttps://www.msys2.org/news/#2024-02-21-note-to-the-remaining-windows-7-80-usershttps://www.msys2.org/news/#2024-02-21-note-to-the-remaining-windows-7-80-usersWed, 21 Feb 2024 00:00:00 +0000 Note to Windows 7 / 8.0 users: While we stopped supporting these systems over a year ago, many things in MSYS2 continued to work as before. With the upcoming update to Cygwin 3.5, this will change and MSYS2 will no longer start on these systems. We're trying to come up with a migration path, but it's not clear yet if and how this will work. We'll post here when we know more. Removal of non C/C++ packages from the mingw-w64-toolchain grouphttps://www.msys2.org/news/#2024-02-19-removal-of-non-cc-packages-from-the-mingw-w64-toolchain-grouphttps://www.msys2.org/news/#2024-02-19-removal-of-non-cc-packages-from-the-mingw-w64-toolchain-groupMon, 19 Feb 2024 00:00:00 +0000 Unlike the LLVM variant, the GCC variant of the <a href="https://packages.msys2.org/basegroups/mingw-w64-toolchain">mingw-w64-toolchain</a> package group also contained non C/C++ toolchains, such as fortran/ada/objc/libgccjit due to the nature of them being built from the same source. Since this was never the intention of the group and was causing a lot of unnecessary downloads and bandwidth usage, we decided to clean this up now. If this broke things for you, make sure you explicitly install <a href="https://packages.msys2.org/base/mingw-w64-gcc">Fortran/Ada/ObjC packages</a> if you depend on them. mingw-w64-gettext converted to split packagehttps://www.msys2.org/news/#2024-02-01-mingw-w64-gettext-converted-to-split-packagehttps://www.msys2.org/news/#2024-02-01-mingw-w64-gettext-converted-to-split-packageThu, 01 Feb 2024 00:00:00 +0000 <a href="https://packages.msys2.org/base/mingw-w64-gettext">mingw-w64-gettext</a> has been split into "gettext-tools" and "gettext-runtime" subpackages. While this is a backwards compatible change, this means that the gettext tools, like msgmerge and msgfmt, are less likely to be installed as transitive dependencies via other packages, and may now be missing for you if you were implicitly depending on them. If this broke things for you, make sure you explicitly install the <a href="https://packages.msys2.org/base/mingw-w64-gettext">gettext tools</a> if you depend on them. Starting to drop some 32-bit Packageshttps://www.msys2.org/news/#2023-12-13-starting-to-drop-some-32-bit-packageshttps://www.msys2.org/news/#2023-12-13-starting-to-drop-some-32-bit-packagesWed, 13 Dec 2023 00:00:00 +0000 Three years ago we dropped 32-bit Windows support for running MSYS2 itself, now we are taking the next step and slowly starting to reduce the number of 32-bit packages, meaning the packages for the MINGW32 and CLANG32 environments. The goal of the phase-out is to reduce maintenance costs and server resources while not affecting most users. The focus will be on packages that aren't likely to see much use anyway, or where 64-bit alternatives are available and viable: <ul> <li>Packages which are likely not used outside of MSYS2 (re-packaged)</li> <li>End-user applications which are likely not used outside of MSYS2 (GUI apps, ...)</li> <li>Packages for resource intensive work where most external users are likely already on 64-bit (some scientific packages, ...)</li> <li>Leaf packages with complex and resource intensive builds that are likely not used</li> <li>New leaf packages</li> </ul> To find out if a package you have installed is affected you can run <code>pacman -Qm</code> which lists all installed packages which are no longer available in the repo. Ideally not many people should notice these changes, but in case they affect you: <ul> <li>Switch your workflow to use 64-bit packages instead ;)</li> <li>Tell us which packages that were removed you still need, so we can consider reinstating them. Please use the <a href="https://github.com/msys2/MINGW-packages/issues/new?assignees=&labels=package-request&projects=&template=environment_request.yml&title=Build+%5Bpackage+name%5D+for+%5Benvironment%5D">issue template</a> to file your request.</li> </ul> If you are wondering if you should continue to support 32-bit Windows for your users, here are some relevant resources: Usage stats: <ul> <li><a href="https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam">https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam</a> 32-bit Win8.1+ below the list threshold. Heavily biased towards newer hardware though.</li> <li><a href="https://www.pcbenchmarks.net/os-marketshare.html">https://www.pcbenchmarks.net/os-marketshare.html</a> 32-bit users at ~0.1%. Heavily biased towards newer hardware though.</li> <li><a href="https://data.firefox.com/dashboard/hardware">https://data.firefox.com/dashboard/hardware</a> 32-bit at ~14%, but this includes ~11% Win7 and other operating systems which we don't support, so it's not clear.</li> <li>In MSYS2 32-bit packages made up ~3.95% of all downloads at the end of 2023, and ~6.45% one year before (ignoring CI downloads)</li> </ul> Some applications dropping 32-bit support: <ul> <li><a href="https://krita.org/">Krita</a> dropped 32-bit support in 2021</li> <li><a href="https://www.qbittorrent.org/">qBittorrent</a> dropped 32-bit support in 2022</li> <li><a href="https://keepassxc.org">KeePassXC</a> dropped 32-bit support in 2022</li> <li><a href="https://scipy.org/">SciPy</a> dropped 32-bit support in 2022</li> </ul> There are of course lots of applications not planning to drop support and 32-bit Windows is still supported until at least October 2025, so we understand that 32-bit support is still required in various cases, and we will try to keep important packages around for as long as possible. Package installation issues for very old/outdated installationshttps://www.msys2.org/news/#2023-11-05-package-installation-issues-for-very-oldoutdated-installationshttps://www.msys2.org/news/#2023-11-05-package-installation-issues-for-very-oldoutdated-installationsSun, 05 Nov 2023 00:00:00 +0000 If you haven't updated pacman in 2.5 years or longer, but are installing new packages, you will see errors like this, due to a format change in the package database: <div class="highlight"><pre><code>error: mingw-w64-ucrt-x86_64-shared-mime-info: missing required signature error: mingw-w64-ucrt-x86_64-gtk3: missing required signature error: failed to commit transaction (package missing required signature) Errors occurred, no packages were upgraded. </code></pre></div> This can be fixed by <a href="https://www.msys2.org/docs/updating/">updating your installation</a>. Python: Changed behavior when loading DLL dependencies of extension moduleshttps://www.msys2.org/news/#2023-08-06-python-changed-behavior-when-loading-dll-dependencies-of-extension-moduleshttps://www.msys2.org/news/#2023-08-06-python-changed-behavior-when-loading-dll-dependencies-of-extension-modulesSun, 06 Aug 2023 00:00:00 +0000 Starting with CPython 3.8, upstream CPython changed their DLL lookup behavior to a safer default when loading extension modules, which meant no longer looking in PATH and the current working directory as a fallback, but requiring code to explicitly add directories containing dependencies via <a href="https://docs.python.org/3/library/os.html#os.add_dll_directory"><code>os.add_dll_directory()</code></a>. Because many packages weren't ported yet back then, and this behavior interfered with our MinGW port build process we reverted this change and kept the old behavior. This had the downsides of being less secure and <code>os.add_dll_directory()</code> not working. We have now finally managed to fix this in our port, so that DLL loading works the same as with the official CPython distribution. If this change is causing problems for you: <ul> <li>Make sure to use <code>os.add_dll_directory()</code> where needed, as recommended by upstream, see <a href="https://docs.python.org/3/library/os.html#os.add_dll_directory">https://docs.python.org/3/library/os.html#os.add_dll_directory</a> for details</li> <li>To ease the transition we've temporarily added a <code>PYTHONLEGACYWINDOWSDLLLOADING</code> environment variable, which you can set to <code>1</code> to get back the old behavior. We will remove this workaround after some time, so please let us know if there are any problems that can't be solved without it.</li> </ul> LLVM 16https://www.msys2.org/news/#2023-04-01-llvm-16https://www.msys2.org/news/#2023-04-01-llvm-16Sat, 01 Apr 2023 00:00:00 +0000 LLVM/Clang has now been updated to v16, here are some things to look out for: <ul> <li> Stricter C compiler: Various previously warnings are now errors by default and might make your build fail. See the following for more information: <ul> <li>The upstream changelog entry: <a href="https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html#potentially-breaking-changes">https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html#potentially-breaking-changes</a></li> <li>The Gentoo guide for how to adjust your code for the new stricter defaults: <a href="https://wiki.gentoo.org/wiki/Modern_C_porting">https://wiki.gentoo.org/wiki/Modern_C_porting</a></li> <li>The Gentoo bug which tracks all related issues in Gentoo: <a href="https://bugs.gentoo.org/870412">https://bugs.gentoo.org/870412</a></li> </ul> </li> <li> autoconf bugs: The stricter defaults in clang v16 exposed some autoconf bugs which lead to some compiler checks returning the wrong results. We have backported the respective fixes into all our autoconf versions (2.13, 2.69 and 2.71) and updated autoconf-archive, but this means you will have to run autoreconf to get those fixes. There is also a chance that other checks in configure.ac or m4 macros shipped with your project will need to be updated. So watch out for changes in your configure results. </li> <li> fortran/flang: flang, the llvm based Fortran compiler, is now capable of building some of our Fortran based packages. But despite that, it still has known issues of generating wrong or broken code without warnings and should not be used in production. The same is true for all Fortran based packages we are building with it. </li> <li> Packages not compatible with llvm v16: So we don't have to wait for all packages/projects to support the newest llvm version, we added new packages for llvm v14 and v15 which only contain static builds and are now used by the packages not supporting llvm v16. This currently affects python-llvmlite, openshadinglanguage and include-what-you-use. </li> </ul> Server maintenance on 2023-02-18/19https://www.msys2.org/news/#2023-02-10-server-maintenance-on-2023-02-1819https://www.msys2.org/news/#2023-02-10-server-maintenance-on-2023-02-1819Fri, 10 Feb 2023 00:00:00 +0000 There will be a short server maintenance around the weekend of 2023-02-18/19 which will affect repo.msys2.org, mirror.msys2.org, packages.msys2.org, and some subdomain redirects of our website. Update: all done now Dropping support for Windows 7 and 8.0https://www.msys2.org/news/#2023-01-15-dropping-support-for-windows-7-and-80https://www.msys2.org/news/#2023-01-15-dropping-support-for-windows-7-and-80Sun, 15 Jan 2023 00:00:00 +0000 As announced last April we will no longer support Windows 7 / 8.0 from now on. OpenSSL updated from 1.1.1 to 3.0.xhttps://www.msys2.org/news/#2023-01-15-openssl-updated-from-111-to-30xhttps://www.msys2.org/news/#2023-01-15-openssl-updated-from-111-to-30xSun, 15 Jan 2023 00:00:00 +0000 With v3.0 being out for more than a year and the EOL of v1.1.1 approaching this year we have moved both cygwin and mingw builds to v3.0.x now. If there are any issues let us know. Note that the license of OpenSSL has changed to Apache-2.0 starting with v3. Dropping 32bit support for Qt 6https://www.msys2.org/news/#2023-01-05-dropping-32bit-support-for-qt-6https://www.msys2.org/news/#2023-01-05-dropping-32bit-support-for-qt-6Thu, 05 Jan 2023 00:00:00 +0000 Qt project dropped support for Windows version older than Windows 10 from Qt 6, see this official <a href="https://www.qt.io/blog/qt6-development-hosts-and-targets">blog post</a>. It was also added that we will not have 32 bit x86 Windows support available. With this above condition, we too have very few users who are using 32 bit x86 Windows 10. So, we decided to remove 32 bit builds for Qt 6 and their dependencies. The remaining 32 bit x86 packages which depends on Qt will be linked with Qt 5. With this, our Qt 6 packages will be available for all official <a href="https://doc.qt.io/qt-6/windows.html">Windows platforms</a>. Default _WIN32_WINNT bumped to Windows 8.1 for UCRT environmentshttps://www.msys2.org/news/#2022-12-26-default-_win32_winnt-bumped-to-windows-81-for-ucrt-environmentshttps://www.msys2.org/news/#2022-12-26-default-_win32_winnt-bumped-to-windows-81-for-ucrt-environmentsMon, 26 Dec 2022 00:00:00 +0000 We have bumped the default <code>_WIN32_WINNT</code> version defined in mingw-w64 from Windows 7 to Windows 8.1 for non-arm UCRT environments (CLANG32, CLANG64, UCRT64). For projects that don't define their own <code>_WIN32_WINNT</code> and conditionally include features depending on the minimum supported Windows version this might mean that new builds will start depending on Windows 8.1. MINGW32/64 will default to Windows 7 for a bit longer to smooth over the transition. This is part of our goal to phase out Windows 7 support and target newer Windows versions by default. Dropping Windows 7 support for the MSYS2 installerhttps://www.msys2.org/news/#2022-12-16-dropping-windows-7-support-for-the-msys2-installerhttps://www.msys2.org/news/#2022-12-16-dropping-windows-7-support-for-the-msys2-installerFri, 16 Dec 2022 00:00:00 +0000 The latest release of the MSYS2 installer (v2022-12-16) has dropped support for Windows 7. It will show an error message and abort if started on Windows 7. Changing the default environment from MINGW64 to UCRT64https://www.msys2.org/news/#2022-10-29-changing-the-default-environment-from-mingw64-to-ucrt64https://www.msys2.org/news/#2022-10-29-changing-the-default-environment-from-mingw64-to-ucrt64Sat, 29 Oct 2022 00:00:00 +0000 About 1.5 years ago we started adding a new variant of the MINGW64 environment called <a href="https://www.msys2.org/docs/environments/">UCRT64</a>, which uses the Universal CRT instead of the old msvcrt.dll. Now that all our packages are available in this new environment and a very large percentage of our users (~97%) are on a system that includes UCRT, we recommend it as the default environment instead of MINGW64. The MINGW32/64 environments will continue to exist and there are no plans to remove them, but we will focus our attention more on UCRT64 and the other UCRT-using environments such as CLANG64 and CLANGARM64. mingw packages now built with -D_FORTIFY_SOURCE=2 and -fstack-protector-stronghttps://www.msys2.org/news/#2022-10-23-mingw-packages-now-built-with-d_fortify_source2-and-fstack-protector-stronghttps://www.msys2.org/news/#2022-10-23-mingw-packages-now-built-with-d_fortify_source2-and-fstack-protector-strongSun, 23 Oct 2022 00:00:00 +0000 Our mingw packages will be built with <code>-D_FORTIFY_SOURCE=2</code> and <code>-fstack-protector-strong</code> from now on. New minimum hardware requirements (CPUs from ~2006/7+)https://www.msys2.org/news/#2022-10-18-new-minimum-hardware-requirements-cpus-from-20067https://www.msys2.org/news/#2022-10-18-new-minimum-hardware-requirements-cpus-from-20067Tue, 18 Oct 2022 00:00:00 +0000 As a first step of phasing out support for Windows 7, we're raising the minimum hardware requirements to match Windows 8.1, which roughly equals Intel Core 2 / AMD Phenom, so anything after 2006/7 is fine. In terms of GCC/Clang compiler flags this means going from <code>-march=x86-64</code> to <code>-march=nocona -msahf</code>. This only affects 64bit packages, and only those that use features only available in those newer CPUs, and only once they are updated or rebuilt. libssp is no longer requiredhttps://www.msys2.org/news/#2022-10-10-libssp-is-no-longer-requiredhttps://www.msys2.org/news/#2022-10-10-libssp-is-no-longer-requiredMon, 10 Oct 2022 00:00:00 +0000 Building with <code>_FORTIFY_SOURCE</code> no longer requires explicitly linking with libssp (-lssp) and enabling stack protection no longer pulls in libssp. This brings things in line with other platforms. Thanks to <a href="https://github.com/mstorsjo">Martin Storsjö</a> for implementing this in mingw-w64. Once all our affected packages are rebuilt we will remove the libssp package from our repo. 2022-10-13: We have decided to keep just the libssp DLL around for some more time to avoid breaking existing users Changed behavior for empty env varshttps://www.msys2.org/news/#2022-09-24-changed-behavior-for-empty-env-varshttps://www.msys2.org/news/#2022-09-24-changed-behavior-for-empty-env-varsSat, 24 Sep 2022 00:00:00 +0000 Empty environment variables are no longer removed when starting a new non-cygwin process. <div class="highlight"><pre><code>$ FOO= python -c "import os; print('FOO' in os.environ)" # Old False $ FOO= python -c "import os; print('FOO' in os.environ)" # New True </code></pre></div> You can revert to the old behavior by setting <code>MSYS=noemptyenvvalues</code>. Please let us know if this is breaking anything that can't be solved by just unsetting the env var where needed. ConPTY support enabled by defaulthttps://www.msys2.org/news/#2022-09-24-conpty-support-enabled-by-defaulthttps://www.msys2.org/news/#2022-09-24-conpty-support-enabled-by-defaultSat, 24 Sep 2022 00:00:00 +0000 ConPTY support in our cygwin fork is now enabled by default. This means any non-cygwin apps will now behave as if they are run in with a console attached and not redirected. This feature has been enabled in upstream cygwin for quite a while but we wanted to wait until there are no more known issues. We now feel that not enabling it causes more problems then enabling it. You can disable it again by setting <code>MSYS=disable_pcon</code>. Windows 7 / 8 support will be dropped late 2022 or early 2023https://www.msys2.org/news/#2022-04-06-windows-7-8-support-will-be-dropped-late-2022-or-early-2023https://www.msys2.org/news/#2022-04-06-windows-7-8-support-will-be-dropped-late-2022-or-early-2023Wed, 06 Apr 2022 00:00:00 +0000 Cygwin 3.5 will drop support for Windows <8.1, which means the new requirement will be "64 bit Windows 8.1 / Windows Server 2012 R2". We expect the update to Cygwin 3.5 to be around late 2022, early 2023. For more information, look <a href="https://www.msys2.org/docs/windows_support/">here</a>. A recent survey suggests that ~2-3% of our active users (excluding cloud servers and CI systems) are still using Windows <8.1. We recommend them stopping to update at the end of the year. We've enabled an inline warning message for them when they open a terminal. For developers bundling our packages, we recommend simply pointing out the last version of their application that still worked with Windows 7 / 8 on their download page. Sunsetting the SourceForge mirror in 30 days from nowhttps://www.msys2.org/news/#2022-03-04-sunsetting-the-sourceforge-mirror-in-30-days-from-nowhttps://www.msys2.org/news/#2022-03-04-sunsetting-the-sourceforge-mirror-in-30-days-from-nowFri, 04 Mar 2022 00:00:00 +0000 Note: This should only affect systems not updated in over a year, or users that actively switched to this mirror, which is unlikely. Due to space constrains and our ever growing package archive we can no longer update the <a href="https://sourceforge.net/projects/msys2/files/">SourceForge mirror</a>. We already hit the space limit last year but worked around it by no longer syncing source packages. We have now hit the limit again, and decided that it is no longer worth it maintaining it. We will remove the SourceForge mirror on 2022-04-03. We will delete the package databases as well to make DB syncs fail to avoid users using outdated software without them knowing it. After 4 more weeks we will delete the remaining packages and installers. 2022-05-07: The mirror has now been removed. repo.msys2.org only available via HTTPS/TLShttps://www.msys2.org/news/#2022-02-24-repomsys2org-only-available-via-httpstlshttps://www.msys2.org/news/#2022-02-24-repomsys2org-only-available-via-httpstlsThu, 24 Feb 2022 00:00:00 +0000 We have switched repo.msys2.org to always redirect to a secure connection. If for some reason you require HTTP you can use one of our <a href="https://www.msys2.org/dev/mirrors/">tier 1 mirrors</a>. Ongoing Cleanup of the base-devel Package Grouphttps://www.msys2.org/news/#2021-12-22-ongoing-cleanup-of-the-base-devel-package-grouphttps://www.msys2.org/news/#2021-12-22-ongoing-cleanup-of-the-base-devel-package-groupWed, 22 Dec 2021 00:00:00 +0000 The <code>base-devel</code> package group is the set of packages required to be installed before running <code>makepkg</code> / <code>makepkg-mingw</code>. We have recently started to clean this group up and moved some of the packages to be explicit dependencies in the <code>PKGBUILD</code> files instead. One notable removal is various autotools related packages. There now exists an <code>autotools</code> and a <code>${MINGW_PACKAGE_PREFIX}-autotools</code> meta package which will pull in anything related to autotools which packages can add to their <code>makedepends</code>. Further more the group was replaced with a package of the same name, to make adding/removing packages easier. Note that pacman prefers packages over groups for the same name, so the set of included packages is now listed here <a href="https://packages.msys2.org/package/base-devel">https://packages.msys2.org/package/base-devel</a> This cleanup can lead to build errors in case your build setup assumes certain packages being installed with <code>base-devel</code>. If that is the case make sure to install those missing packages explicitly instead. Potential Incompatibilities with newer Python setuptoolshttps://www.msys2.org/news/#2021-12-21-potential-incompatibilities-with-newer-python-setuptoolshttps://www.msys2.org/news/#2021-12-21-potential-incompatibilities-with-newer-python-setuptoolsTue, 21 Dec 2021 00:00:00 +0000 tl;dr: use <code>export SETUPTOOLS_USE_DISTUTILS=stdlib</code> if you have problems building/installing packages with newer versions of setuptools from pypi. The Python packaging ecosystem is currently in the transition of removing distutils from CPython and moving it into setuptools. Historically distutils is patched quite a bit by us to make it work with our directory layout and to build packages with gcc/clang instead of MSVC. With this move our patches are no longer used and setuptools will fail in various ways, or install things into wrong places. We are working with upstream to include our patches, but this will take some more time. In the meantime you can force setuptools to use the (still patched) distutils from the CPython stdlib via <code>export SETUPTOOLS_USE_DISTUTILS=stdlib</code> The setuptools version in our repo however will continue to use the patched distutils until all issues are resolved and is not affected. 🙏 Many thanks to the distutils and setuptools maintainers for considering our patches, despite Cygwin/MSYS2 not being officially supported by CPython. OpenSSH 8.8 dropped support for old ssh-rsa keys using SHA-1https://www.msys2.org/news/#2021-10-14-openssh-88-dropped-support-for-old-ssh-rsa-keys-using-sha-1https://www.msys2.org/news/#2021-10-14-openssh-88-dropped-support-for-old-ssh-rsa-keys-using-sha-1Thu, 14 Oct 2021 00:00:00 +0000 The recent OpenSSH update disabled support for old ssh-rsa keys using SHA-1 by default. See <a href="https://www.openssh.com/txt/release-8.8">https://www.openssh.com/txt/release-8.8</a> "Potentially-incompatible changes" for details and possible workarounds. Some Mirror/Server/Repository Changeshttps://www.msys2.org/news/#2021-07-04-some-mirrorserverrepository-changeshttps://www.msys2.org/news/#2021-07-04-some-mirrorserverrepository-changesSun, 04 Jul 2021 00:00:00 +0000 Primary Pacman Server: We've switched the main server in the pacman config to <a href="https://mirror.msys2.org">https://mirror.msys2.org</a>. This server will redirect pacman to an up-to-date mirror <a href="https://mirror.msys2.org/?mirrorstats">near you</a> for each file. We hope this will improve the download speed for users further away from Europe. We also have a new overview of all mirrors <a href="https://www.msys2.org/dev/mirrors/">here</a>. Repo Path Renaming: We've renamed <code>mingw/i686/</code> to <code>mingw/mingw32/</code> and <code>mingw/x86_86/</code> to <code>mingw/mingw64/</code> and added symlinks for the old paths. This means 100GB of resyncing for mirrors using rsync (sorry :/). Having the repo name in the directory path allows us to have one mirrorlist configuration for all repos in the future. Sourceforge: Due to space constraints we no longer host the source packages on Sourceforge. They are still available on our main server and on all mirrors. R.I.P. mingwandroidhttps://www.msys2.org/news/#2021-04-21-rip-mingwandroidhttps://www.msys2.org/news/#2021-04-21-rip-mingwandroidWed, 21 Apr 2021 00:00:00 +0000 Ray Donnelly is a co-founder and developer of MSYS2 and after a multi year fight with cancer passed away on 2021-04-20. <img alt="ray" height="666" src="https://www.msys2.org/ray.jpg" style="max-width: 375px; width:100%; border: 2px solid #333; box-shadow: 0px 0px 3px #ccc;" width="999"/> If you want to know more about his life and work see his fundraiser descriptions: <ul> <li><a href="https://www.gofundme.com/f/help-Ray-fund-a-hospice-bedroom">https://www.gofundme.com/f/help-Ray-fund-a-hospice-bedroom</a></li> <li><a href="https://www.gofundme.com/f/arku72-help-ray-fight-cancer">https://www.gofundme.com/f/arku72-help-ray-fight-cancer</a></li> </ul> He was always helpful, knowledgeable, and friendly, and he will be greatly missed. Temporarily broken msys2-launcher packagehttps://www.msys2.org/news/#2021-03-25-temporarily-broken-msys2-launcher-packagehttps://www.msys2.org/news/#2021-03-25-temporarily-broken-msys2-launcher-packageThu, 25 Mar 2021 00:00:00 +0000 The repo contained a broken msys2-launcher package for a few hours today causing things like "msys2.exe" to just show an error dialog. You can get back to a working setup this way: <ul> <li>Start <code>C:/msys64/msys2_shell.cmd</code> to get a shell</li> <li>Run <code>pacman -Suy</code> to get all the fixed packages</li> </ul> New server for repo.msys2.org and packages.msys2.orghttps://www.msys2.org/news/#2021-02-27-new-server-for-repomsys2org-and-packagesmsys2orghttps://www.msys2.org/news/#2021-02-27-new-server-for-repomsys2org-and-packagesmsys2orgSat, 27 Feb 2021 00:00:00 +0000 We have moved repo.msys2.org (and package.msys2.org) to a new server. There was a short downtime, but everything should be running great now. Big thanks to <del>appfleet.com</del> jsdelivr.com for sponsoring the new server. New mirrorlists for Pacman will be published soon. After you get them, your package installs and updates should be faster than before and without the 404s and glitches. With the migration, Christoph (@lazka) will now be updating and signing the Pacman databases more often. This should go smoothly as the GPG keys are already in place and the process has been tested on the new server before it went live. By the way, the redirect domain msys2.org (no www.) should work more reliably now and HTTPS is now available for it. ASLR enabled by defaulthttps://www.msys2.org/news/#2021-01-31-aslr-enabled-by-defaulthttps://www.msys2.org/news/#2021-01-31-aslr-enabled-by-defaultSun, 31 Jan 2021 00:00:00 +0000 About 5 months ago we started backporting patches to our binutils 2.35 to allow enabling ASLR support via various flags. We also enabled these flags in our build system, so any package in our repo that was updated in the last 5 months has ASLR support enabled. We've now updated to 2.36 which has ASLR enabled by default. Ideally you shouldn't notice any changes, but in case this leads to problems all of it can be disabled/reverted via linker flags: <ul> <li>mingw64: <code>-Wl,--disable-dynamicbase,--disable-high-entropy-va,--default-image-base-low</code></li> <li>mingw32: <code>-Wl,--disable-dynamicbase</code></li> </ul> Note that this is only a temporary workaround and some of these flags will not be available forever, so you should either fix your code or file a bug in case you suspect a toolchain issue. Thanks to the binutils developers for improving/fixing ASLR support and to everyone helping on the MSYS2 side of things, especially <a href="https://github.com/jeremyd2019">Jeremy Drake</a> for backporting, upstreaming and fixing bugs exposed by these changes. Known issues: <ul> <li>(Fixed now) <del>In case you are seeing errors such as <code>relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol</code> try building with <code>-Wl,--default-image-base-low</code>. Here is the upstream bug report: <a href="https://sourceware.org/bugzilla/show_bug.cgi?id=26659">https://sourceware.org/bugzilla/show_bug.cgi?id=26659</a></del></li> </ul> Zstd exemption for core packages removedhttps://www.msys2.org/news/#2020-12-26-zstd-exemption-for-core-packages-removedhttps://www.msys2.org/news/#2020-12-26-zstd-exemption-for-core-packages-removedSat, 26 Dec 2020 00:00:00 +0000 Given it's been months since we began the switch to Zstd for compressing packages, we've now started using it for core packages as well. This means older installations without Zstd support won't be able to cleanly upgrade anymore. @dmn-star compiled these commands that should update an older installation to support Zstd and unblock futher upgrades: <div class="highlight"><pre><code>pacman --noconfirm -U "https://repo.msys2.org/msys/x86_64/libzstd-1.4.4-2-x86_64.pkg.tar.xz" pacman --noconfirm -U "https://repo.msys2.org/msys/x86_64/zstd-1.4.4-2-x86_64.pkg.tar.xz" pacman --noconfirm -U "https://repo.msys2.org/msys/x86_64/pacman-5.2.1-6-x86_64.pkg.tar.xz" </code></pre></div> main repo prunedhttps://www.msys2.org/news/#2020-10-08-main-repo-prunedhttps://www.msys2.org/news/#2020-10-08-main-repo-prunedThu, 08 Oct 2020 00:00:00 +0000 Due to limited space on the new server and SourceForge file hosting, we are starting to remove older unused packages from the archives. There should still be a 1 year's worth of packages available for downgrades. Mirrors are free to choose whether they want to keep everything or follow the lead. server downtimehttps://www.msys2.org/news/#2020-10-07-server-downtimehttps://www.msys2.org/news/#2020-10-07-server-downtimeWed, 07 Oct 2020 00:00:00 +0000 From Friday 2nd to Wednesday 10th, the main hosting at repo.msys2.org was down. The server unfortunately completely died and the hosting had to be moved elsewhere. We thank Diablo-D3 for having provided the hardware and hosting. If you notice anything wrong with repo.msys2.org since the move, please tell us. new packagershttps://www.msys2.org/news/#2020-06-29-new-packagershttps://www.msys2.org/news/#2020-06-29-new-packagersMon, 29 Jun 2020 00:00:00 +0000 Alexey is stepping down from his role as the main packager and two new packagers have been appointed in his place: <ul> <li>David Macek with <a href="https://keyserver.ubuntu.com/pks/lookup?search=0x87771331B3F1FF5263856A6D974C8BE49078F532&fingerprint=on&op=vindex">signing key 0x9078f532</a></li> <li>Christoph Reiter with <a href="https://keyserver.ubuntu.com/pks/lookup?search=0x5F944B027F7FE2091985AA2EFA11531AA0AA7F57&fingerprint=on&op=vindex">signing key 0xa0aa7f57</a></li> </ul> You can see the keys in full without relying on keyservers in the <a href="https://github.com/msys2/MSYS2-keyring/">msys2-keyring GitHub repository</a>. We have released a new msys2-keyring package from that source (and a new installer that includes them) and we are waiting for a bit before uploading new databases and packages to give people time to update. If you don't update the keyring in time, you'll see something like this: <div class="highlight"><pre><code>:: Synchronizing package databases... downloading mingw32.db... downloading mingw32.db.sig... error: mingw32: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" is unknown :: Import PGP key 4096R/87771331B3F1FF5263856A6D974C8BE49078F532, "David Macek <david.macek.0@gmail.com>", created: 2018-01-14? [Y/n] error: mingw32: signature from "David Macek <david.macek.0@gmail.com>" is marginal trust error: failed to update mingw32 (invalid or corrupted database (PGP signature)) downloading mingw64.db... downloading mingw64.db.sig... error: mingw64: signature from "David Macek <david.macek.0@gmail.com>" is marginal trust error: failed to update mingw64 (invalid or corrupted database (PGP signature)) downloading msys.db... downloading msys.db.sig... error: msys: signature from "David Macek <david.macek.0@gmail.com>" is marginal trust error: failed to update msys (invalid or corrupted database (PGP signature)) error: failed to synchronize all databases error: mingw32: signature from "David Macek <david.macek.0@gmail.com>" is marginal trust error: mingw64: signature from "David Macek <david.macek.0@gmail.com>" is marginal trust error: msys: signature from "David Macek <david.macek.0@gmail.com>" is marginal trust </code></pre></div> We have prepared the following steps to verify and install the new keyring manually after which you should be able to use <code>pacman -Syu</code> again: <div class="highlight"><pre><code>$ curl -O https://repo.msys2.org/msys/x86_64/msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz $ curl -O https://repo.msys2.org/msys/x86_64/msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz.sig $ pacman-key --verify msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz.sig ==> Checking msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz.sig... (detached) gpg: Signature made Mon Jun 29 07:36:14 2020 CEST gpg: using DSA key AD351C50AE085775EB59333B5F92EFC1A47D45A1 gpg: Good signature from "Alexey Pavlov (Alexpux) <alexpux@gmail.com>" [full] # pacman -U msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz </code></pre></div> If you can't even import the key and the above command fails like this: <div class="highlight"><pre><code>error: msys: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" is unknown :: Import PGP key 4A6129F4E4B84AE46ED7F635628F528CF3053E04? [Y/n] [...] error: database 'msys' is not valid (invalid or corrupted database (PGP signature)) loading packages... error: failed to prepare transaction (invalid or corrupted database) </code></pre></div> ... you have to convince pacman to not care about those databases for a while, for example like this: <div class="highlight"><pre><code># pacman -U --config <(echo) msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz </code></pre></div> If you still see signature errors, resetting your pacman key store might help: <div class="highlight"><pre><code># rm -r /etc/pacman.d/gnupg/ # pacman-key --init # pacman-key --populate msys2 </code></pre></div> New base metapackage; pacman-contrib is now separatehttps://www.msys2.org/news/#2020-06-15-new-base-metapackage-pacman-contrib-is-now-separatehttps://www.msys2.org/news/#2020-06-15-new-base-metapackage-pacman-contrib-is-now-separateMon, 15 Jun 2020 00:00:00 +0000 Following a similar change in Arch Linux, the <code>base</code> group was replaced with a <code>base</code> metapackage. If you installed your MSYS2 using an installer older than 2020-06-02, please run <code>pacman -S base</code> to get up to date. This also installs the <code>pacman-contrib</code> package where <code>updpkgsums</code>, <code>pactree</code> etc. now live (previously included in the <code>pacman</code> package). Details at <a href="https://github.com/msys2/MSYS2-packages/pull/1979">#1979</a>, <a href="https://github.com/msys2/MSYS2-packages/issues/1976">#1976</a> and <a href="https://github.com/msys2/MSYS2-packages/pull/1988">#1988</a>. Update may fail with "could not open file"https://www.msys2.org/news/#2020-05-31-update-may-fail-with-could-not-open-filehttps://www.msys2.org/news/#2020-05-31-update-may-fail-with-could-not-open-fileSun, 31 May 2020 00:00:00 +0000 In case your update process errors out with something similar to <blockquote> error: could not open file /var/cache/pacman/pkg/zstd-1.4.5-1-x86_64.pkg.tar.zst: Child process exited with status 127 </blockquote> update pacman separately first: <div class="highlight"><pre><code>pacman -Sydd pacman </code></pre></div> This issue is caused by a pacman version that is too old and can't handle newer packages compressed with zstd. In case you are seeing this problem in CI consider using a newer base which contains a newer pacman which supports zstd: <a href="https://github.com/msys2/msys2-installer/releases">https://github.com/msys2/msys2-installer/releases</a> MSYS2 may fail to start after a msys2-runtime upgradehttps://www.msys2.org/news/#2020-05-22-msys2-may-fail-to-start-after-a-msys2-runtime-upgradehttps://www.msys2.org/news/#2020-05-22-msys2-may-fail-to-start-after-a-msys2-runtime-upgradeFri, 22 May 2020 00:00:00 +0000 MSYS2 programs will fail to start if programs started before the update are still running in the background (especially sshd, dirmngr, gpg-agent, bash, pacman and mintty). You can stop them by running the following in a Windows terminal: <div class="highlight"><pre><code>taskkill /f /fi "MODULES eq msys-2.0.dll" </code></pre></div> If that fails, try a reboot. We've improved our update process so this shouldn't happen again with future updates. Pacman may fail to install packages with Unrecognized archive formathttps://www.msys2.org/news/#2020-05-22-pacman-may-fail-to-install-packages-with-unrecognized-archive-formathttps://www.msys2.org/news/#2020-05-22-pacman-may-fail-to-install-packages-with-unrecognized-archive-formatFri, 22 May 2020 00:00:00 +0000 For a while, the core packages were prematurely packaged using zstd without giving users time to update to zstd-enabled pacman first. This should be resolved now. 32-bit MSYS2 no longer actively supportedhttps://www.msys2.org/news/#2020-05-17-32-bit-msys2-no-longer-actively-supportedhttps://www.msys2.org/news/#2020-05-17-32-bit-msys2-no-longer-actively-supportedSun, 17 May 2020 00:00:00 +0000 32-bit mingw-w64 packages are still supported, this is about the POSIX emulation layer, i.e. the runtime, Bash, MinTTY... After this date, we don't plan on building updated msys-i686 packages nor releasing i686 installers anymore. This is due to increasingly frustrating difficulties with limited 32-bit address space, high penetration of 64-bit systems and Cygwin (our upstream) starting their way to drop 32-bit support as well. mingw-w64 Ada and ObjC unsupported until further noticehttps://www.msys2.org/news/#2019-06-03-mingw-w64-ada-and-objc-unsupported-until-further-noticehttps://www.msys2.org/news/#2019-06-03-mingw-w64-ada-and-objc-unsupported-until-further-noticeMon, 03 Jun 2019 00:00:00 +0000 Pacman may say this when updating: <div class="highlight"><pre><code>looking for conflicting packages... error: failed to prepare transaction (could not satisfy dependencies) :: installing mingw-w64-x86_64-gcc (9.1.0-1) breaks dependency 'mingw-w64-x86_64-gcc=8.3.0-2' required by mingw-w64-x86_64-gcc-ada :: installing mingw-w64-x86_64-gcc (9.1.0-1) breaks dependency 'mingw-w64-x86_64-gcc=8.3.0-2' required by mingw-w64-x86_64-gcc-objc :: installing mingw-w64-x86_64-gcc (9.1.0-1) breaks dependency 'mingw-w64-i686-gcc=8.3.0-2' required by mingw-w64-i686-gcc-ada :: installing mingw-w64-x86_64-gcc (9.1.0-1) breaks dependency 'mingw-w64-i686-gcc=8.3.0-2' required by mingw-w64-i686-gcc-objc </code></pre></div> Ada and ObjC are currently unsupported in MSYS2 builds due to long-standing issues with the i686 variant. Run <code>pacman -R mingw-w64-x86_64-gcc-ada mingw-w64-x86_64-gcc-objc</code> and/or <code>pacman -R mingw-w64-i686-gcc-ada mingw-w64-i686-gcc-objc</code>, then update. Core update integrated into Pacman; update-core removedhttps://www.msys2.org/news/#2016-07-15-core-update-integrated-into-pacman-update-core-removedhttps://www.msys2.org/news/#2016-07-15-core-update-integrated-into-pacman-update-core-removedFri, 15 Jul 2016 00:00:00 +0000 The function of <code>update-core</code> is transferred to <code>pacman -Syuu</code>. Command window may linger after startuphttps://www.msys2.org/news/#2016-04-05-command-window-may-linger-after-startuphttps://www.msys2.org/news/#2016-04-05-command-window-may-linger-after-startupTue, 05 Apr 2016 00:00:00 +0000 Change the argument <code>/K</code> to <code>/C</code> in all three Start menu shortcuts.