setup-msys2: signature from "Alexey Pavlov (Alexpux) " is invalid
I’m getting many errors about invalid signatures in my CI:
2020-12-30T07:53:10.1381061Z error: mingw-w64-x86_64-icu: signature from "Alexey Pavlov (Alexpux) <alexpux@gmail.com>" is invalid
2020-12-30T07:53:10.1382702Z :: File /var/cache/pacman/pkg/mingw-w64-x86_64-icu-68.2-1-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
2020-12-30T07:53:10.1395297Z Do you want to delete it? [Y/n] error: mingw-w64-x86_64-boost: signature from "Alexey Pavlov (Alexpux) <alexpux@gmail.com>" is invalid
2020-12-30T07:53:10.1396779Z
2020-12-30T07:53:10.1398296Z :: File /var/cache/pacman/pkg/mingw-w64-x86_64-boost-1.75.0-1-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
2020-12-30T07:53:10.1416780Z Do you want to delete it? [Y/n] error: mingw-w64-x86_64-harfbuzz: signature from "Alexey Pavlov (Alexpux) <alexpux@gmail.com>" is invalid
2020-12-30T07:53:10.1418414Z
2020-12-30T07:53:10.1419562Z :: File /var/cache/pacman/pkg/mingw-w64-x86_64-harfbuzz-2.7.3-1-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
2020-12-30T07:53:10.1420770Z Do you want to delete it? [Y/n] error: failed to commit transaction (invalid or corrupted package)
2020-12-30T07:53:10.1731366Z
2020-12-30T07:53:10.1734005Z Errors occurred, no packages were upgraded.
2020-12-30T07:53:10.1797630Z ##[error]The process 'C:\windows\system32\cmd.exe' failed with exit code 1
Similar to these: https://github.com/Alexpux/MSYS2-pacman/issues/58
Is it a problem only in this repo or in all of msys2 or all of pacman?
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 26 (10 by maintainers)
Commits related to this issue
- Github Actions: Enforce a cache miss on Windows job Workaround discuted in msys2/setup-msys2#99. — committed to WerWolv/ImHex by deleted user 4 years ago
- try workaround invalid msys2 package cache See https://github.com/msys2/setup-msys2/issues/99 — committed to mltframework/shotcut by ddennedy 3 years ago
- Try a goofy workaround suggeted in the https://github.com/msys2/setup-msys2/issues/99 thread. — committed to naev/naev by UncombedCoconut 3 years ago
- Revert "Try a goofy workaround suggeted in the https://github.com/msys2/setup-msys2/issues/99 thread." This reverts commit 39e07730836149cfb90a4b37e565d38dce421fc7. — committed to UncombedCoconut/naev by UncombedCoconut 3 years ago
- Revert "Try a goofy workaround suggeted in the https://github.com/msys2/setup-msys2/issues/99 thread." This reverts commit 39e07730836149cfb90a4b37e565d38dce421fc7. — committed to UncombedCoconut/naev by UncombedCoconut 3 years ago
- Revert "Try a goofy workaround suggeted in the https://github.com/msys2/setup-msys2/issues/99 thread." This reverts commit 39e07730836149cfb90a4b37e565d38dce421fc7. — committed to UncombedCoconut/naev by UncombedCoconut 3 years ago
- Revert "Try a goofy workaround suggeted in the https://github.com/msys2/setup-msys2/issues/99 thread." This reverts commit 39e07730836149cfb90a4b37e565d38dce421fc7. — committed to UncombedCoconut/naev by UncombedCoconut 3 years ago
- Revert "Try a goofy workaround suggeted in the https://github.com/msys2/setup-msys2/issues/99 thread." This reverts commit 39e07730836149cfb90a4b37e565d38dce421fc7. — committed to UncombedCoconut/naev by UncombedCoconut 3 years ago
- cache: add CACHE_FLUSH_COUNTER (#99) — committed to msys2/setup-msys2 by eine 3 years ago
some packages got incorrectly replaced and the package caching in setup-msys2/pacman doesn’t like that. should be fixed in the next upload
stupid workaround: reorder the packages in the "install: " part of the setup-msys2 action, that will trigger a cache miss.
sure.
(I’ll look into building a new installer today)
@lazka, can be we think about a mechanism for flushing the cache? That is, do not load it but have it saved. I’m not sure whether it should be an option in the Action (which users would need to commit in and commit out); or parsing the commit message looking for something such as
[skip cache]; or both options.My main concern is that a simple “clean” run might not suffice. Are cache hits guaranteed to find the latest match?
@umarcor No. I tried to just change the install field and it didn’t not work for me. Here are two consecutive commits that I made:
https://github.com/pcb2gcode/pcb2gcode/pull/493/commits/ba92e2f962b3185ad8b1aba82047b2acd19a7aa3
https://github.com/pcb2gcode/pcb2gcode/pull/493/commits/19a114f03cb42678d17cbbabece921e33967d718
Here are the corresponding CI runs:
https://github.com/pcb2gcode/pcb2gcode/runs/1628278503
https://github.com/pcb2gcode/pcb2gcode/runs/1628833615
You can see that they are both failing even though I have made a brand-new list of installs.
If I look in the log, they have this:
Notice that they are requesting different restores. One is
69592945and the other is6f832eb4. But they are both getting the same one, even though the request was not the same. They are both getting67967524. That’s weird.I think that the caching action that GitHub provides uses a prefix, where if a cached item is not found, it looks for something by prefix. Because the prefixes match, maybe it’s taking the wrong one? I’ll will read about it.