MSYS2 builds broken

[lovetox]

It seems something changed and im getting lot of these on various packages that i want to install

installing gmp...
      1 [main] bash (1600) C:\msys64\home\appveyor\gajim\win\_build_root\usr\bin\bash.exe: *** fatal error - cygheap base mismatch detected - 0x1802F6408/0x1802FF410.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version.  The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if you
are unable to find another cygwin DLL.

i didnt have these problems 3 days ago, and i changed nothing on the build script

https://ci.appveyor.com/project/yann-l/gajim/build/1.0.319 - build ok
https://ci.appveyor.com/project/yann-l/gajim/build/1.0.320 - build fails

[lovetox]

seems that removing

pacman -Rdd catgets libcatgets

solves the problem

seems there was a runtime update of msys, would be nice if you could update the default msys installation

[FeodorFitsner]

Thanks for the solution. Will update MSYS2 during the next update.

[lovetox]

@FeodorFitsner

Seems after the usual

pacman -Syu --noconfirm at the beginning where we update the msys2 core libs

this time there were incompatibilites with these 2 packages, the problem why the builds failed was that the usuall --noconfirm does not uninstall the incompatible libs when asked by msys2.

this was adressed in this issue here: msys2/MSYS2-packages#1141

so not strictly a appveyor problem

the problem was fixed upstream, a work around until this lands is

pacman -Syuu --needed --noconfirm --ask=127

the `--ask=127´ answers all questions with ´yes´

[Ede123]

Upstream issue: msys2/MSYS2-packages#1141

For the workaround please note:

• It has to be --ask=20.
• The option --ask is meant for internal usage only (i.e. running unittests). It's undocumented and was even temporarily removed by pacman developers at some point. It's not meant for usage by end-users.

The upstream repo already has an updated version of pacman which will avoid this issue in future by changing the default answer of all questions to "yes", so --noconfirm will always work as expected (by automatically confirming with "yes").
Because of the unintuitive behavior of the --ask option using the workaround described above will actually regress the behavior again if not removed in time (see also the upstream issue for some ongoing discussion on this).