Msys2-packages: Unable to build my softwares pacman packages anymore

[KrullBorg]

today, after some week, i tried to build my softwares pacman files, but i have a some problems (i didn't try msys/mingw official packages)

running "makepkg-mingw -cLf" sometimes i get error on prepare stage "tee: standard input: Invalid argument"

instead, when it goes forward, it hangs at the end of building, before doing the package file, no errors

[...]
make[3]: uscita dalla directory «/home/tux/msys2/packages/mingw-w64-infanzia/src/build-x86_64-w64-mingw32/installers»
make[2]: uscita dalla directory «/home/tux/msys2/packages/mingw-w64-infanzia/src/build-x86_64-w64-mingw32/installers»
make[2]: ingresso nella directory «/home/tux/msys2/packages/mingw-w64-infanzia/src/build-x86_64-w64-mingw32»
make[2]: uscita dalla directory «/home/tux/msys2/packages/mingw-w64-infanzia/src/build-x86_64-w64-mingw32»
make[1]: uscita dalla directory «/home/tux/msys2/packages/mingw-w64-infanzia/src/build-x86_64-w64-mingw32»

i tought it was a tee bug, even because in conemu status bar i saw the tee process running; so i downgrade coreutils package, but same problems

what could it be?

thanks in advance

[KrullBorg]

update: i found some strange processes in task manager named like " ����000400000007141CD7D0DF263BB39A42" after i cannot exit from conemu with msys bash; it exiited after i killed these processes; and i found these processes also if i not tried to build something

[KrullBorg]

one of the packages that i tried to build
https://saetta.ns0.it/gitweb?p=msys2;a=blob;f=packages/mingw-w64-infanzia/PKGBUILD;h=f0682569cce047be99d005c82092f6f4ed9c3d9b;hb=HEAD

[lazka]

Can you try MSYS=disable_pcon

[KrullBorg]

nothing to do

[umarcor]

I think I'm hitting a similar issue. After updating from 20190524 to 20200517, some PKGBUILD files that used to work now hang after build(). This is a successful log from two days ago: https://github.com/ghdl/ghdl/runs/684235019?check_suite_focus=true#step:4:1141. Note that ==> Starting package()... is executed right after mv libghdl-1_0_dev.dll.exe libghdl-1_0_dev.dll. However, now, the process hangs before starting package(): https://github.com/ghdl/ghdl/runs/688963452?check_suite_focus=true#step:4:1144

Surprisingly, I found it to happen on GitHub Actions, but I cannot reproduce locally. The workflow to reproduce it is the following: https://github.com/umarcor/ghdl/blob/35457c90e0cf9cb3ff45a1a67037f3bc57b48c16/.github/workflows/push.yml#L44-L68

My current workaround is to split building and packaging, and to explicitly exit from build(): https://github.com/umarcor/ghdl/commit/35457c90e0cf9cb3ff45a1a67037f3bc57b48c16.

@lazka, I tried MSYS=disable_pcon, but as @KrullBorg said, it made no difference: https://github.com/umarcor/ghdl/runs/690968621?check_suite_focus=true#step:5:1029

[KrullBorg]

i tried to downgrade msys-runtime, msys-runtime-devel (3.0.7), mingw-gcc* (9.3) but nothing; i can build the softwares from sources in the classic way (cd <>; ./configure; make; make install)

[lazka]

probably unrelated.. @eine looking at https://github.com/ghdl/ghdl/runs/688963452?check_suite_focus=true#step:4:1144 isn't the final system upgrade missing? (it updates pacman, then does a core update, but then no follow up if I'm not mistaken)

[Delagen]

Seems in latest update msys-2.0.dll broken dated 2020-05-18

[eine]

@lazka, the procedure is https://github.com/eine/setup-msys2/blob/master/main.js#L54-L64:

pacman --noconfirm -Sy
pacman --noconfirm --needed -S bash pacman
taskkill /IM gpg-agent.exe /F
taskkill /IM dirmngr.exe /F
pacman --noconfirm -Suu

Should I add another -Syuu or -Syu at the end?

[mati865]

@eine you have to kill the process after upgrading msys2-runtime not before.

[lazka]

Should I add another -Syuu or -Syu at the end?

yes

[eine]

@mati865, @lazka thanks! This is the new procedure:

pacman --noconfirm -Sy
pacman --noconfirm --needed -S bash pacman
pacman --noconfirm -Suu
taskkill /IM gpg-agent.exe /F
taskkill /IM dirmngr.exe /F
pacman --noconfirm -Syuu

[mati865]

@eine with latest base (2020-05-17) you don't have to upgrade pacman separately.

[eine]

Thanks for the pointer @mati865. However, I'd like to make the procedure as robust as I can for future similar issues. I'm using nightly releases in a branch, and it reuses the same procedure.

As a related question, during the last months, unpacking the release and executing pacman -Syu was enough. Is there any chance to have a new 2020-05-24 release (or any other in the following weeks) which allows it? I believe it would be useful to bump a new release when a critical package (pacman, bash, runtime) needs to be updated.

At the same time, I read somewhere (cannot remember where) that all packages are currently built offline. Is there any plan to use GitHub Actions?

[mati865]

@eine

Thanks for the pointer @mati865. However, I'd like to make the procedure as robust as I can for future similar issues. I'm using nightly releases in a branch, and it reuses the same procedure.

If upgraded pacman depends on newer msys2-runtime than installed one you will end up with broken pacman. The same could be said about bash.

At the same time, I read somewhere (cannot remember where) that all packages are currently built offline. Is there any plan to use GitHub Actions?

Yes, Alexpux personally builds packages and adds them to the repo.

[eine]

If upgraded pacman depends on newer msys2-runtime than installed one you will end up with broken pacman. The same could be said about bash.

So, what is your recommendation?

pacman --noconfirm -Sy
pacman --noconfirm -Suu
taskkill /IM gpg-agent.exe /F
taskkill /IM dirmngr.exe /F
pacman --noconfirm -Syuu

or

pacman --noconfirm -Syuu
taskkill /IM gpg-agent.exe /F
taskkill /IM dirmngr.exe /F
pacman --noconfirm -Syuu

Yes, Alexpux personally builds packages and adds them to the repo.

Is there any plan to use CI (GitHub Actions) instead?

[mati865]

pacman --noconfirm -Syuu
taskkill /IM gpg-agent.exe /F
taskkill /IM dirmngr.exe /F
pacman --noconfirm -Suu

Should be good for nowbut keep in mind that situation with leftover processes can change in the future.

Is there any plan to use CI (GitHub Actions) instead?

I don't know.

[umarcor]

probably unrelated..

It was related. The hang is fixed with latest setup-msys2. Thank you.

[KrullBorg]

trying to build only 32bit version i got

[...]
../../cedolib/src/scuole.c: In function 'scuole_new':
../../cedolib/src/scuole.c: In function 'scuole_new':
../../cedolib/src/scuole.c:143:2: internal compiler error: Segmentation fault
143 | Scuole *a = SCUOLE (g_object_new (scuole_get_type (), NULL));
| ^~

../../cedolib/src/scuole.c:143:2: internal compiler error: Aborted
i686-w64-mingw32-gcc.exe: internal compiler error: Aborted signal terminated program cc1
make[2]: * [Makefile:529: scuola.o] Errore 4
Please submit a full bug report,
with preprocessed source if appropriate.
See https://sourceforge.net/projects/msys2 for instructions.
make[2]: * [Makefile:529: scuole.o] Errore 4
../../cedolib/src/tipirecapito.c: In function 'tipi_recapito_class_init':
../../cedolib/src/tipirecapito.c:102:2: warning: 'g_type_class_add_private' is deprecated [-Wdeprecated-declaration
[...]

[KrullBorg]

i saw that removing all deprecation warnings (a lot but due to the same reason) it works: no crashes

[KrullBorg]

and to date, no more tee errors (for me the issue can be closed)

[lazka]

we got a new cygwin update in the meantime, maybe that helped.

@KrullBorg thanks for the update