-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dev-env: pin msys2/mingw #15311
dev-env: pin msys2/mingw #15311
Conversation
Today the postgresql 12.4 artifacts were purged from the msys2 primary mirrors. I was able to find a copy on some old mirrors (I downloaded from [mirrors.piconets.webwerks.in], [mirrors.aliyun.com], and [mirror.iscas.ac.cn]), but that raised the question of where to put the binary so our CI nodes can access it. I decided to put it on one of our GCS buckets, and while I was there I did the whole msys2 set of packages. Does this manually may not be the best path forward for a long-term solution (though maybe it is; they tend not to change all that often), but it does unblock us right now. For the postgresql binary specifically, I have checked that the three mirrors give me the exact same file between them, and that it matches the old hash. For the other files, I downloaded them from the primary mirror ([repo.msys2.org]) and checked that the hashes match the recorded values in our JSON manifest. CHANGELOG_BEGIN CHANGELOG_END [mirrors.piconets.webwerks.in]: https://mirrors.piconets.webwerks.in/msys2-mirror/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [mirrors.aliyun.com]: https://mirrors.aliyun.com/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst?spm=a2c6h.25603864.0.0.32b23240Qp8jCL [mirror.iscas.ac.cn]: https://mirror.iscas.ac.cn/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [repo.msys2.org]: https://repo.msys2.org/mingw/x86_64/
Note: our Windows CI nodes are currently busted because of the missing PostgreSQL binary in the primary mirrors. They will need to be reset after this gets merged to main. |
@@ -1,7 +1,7 @@ | |||
{ | |||
"homepage": "http://msys2.github.io", | |||
"version": "20220118", | |||
"url": [ | |||
"_url": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this here as a backup or does it have a meaning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is ignored by everything currently. I thought it would be useful to keep track of where the artifacts were originally found. This is not a great long-term solution as there's nothing keeping that in sync with the "local copies" in the GCS bucket, but I thought designing a good long-term solution could wait until we have a working CI again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably worth adding a more descriptive string that _url
, just in case someone wonders about the meaning and you're not around.
* dev-env: pin msys2/mingw Today the postgresql 12.4 artifacts were purged from the msys2 primary mirrors. I was able to find a copy on some old mirrors (I downloaded from [mirrors.piconets.webwerks.in], [mirrors.aliyun.com], and [mirror.iscas.ac.cn]), but that raised the question of where to put the binary so our CI nodes can access it. I decided to put it on one of our GCS buckets, and while I was there I did the whole msys2 set of packages. Does this manually may not be the best path forward for a long-term solution (though maybe it is; they tend not to change all that often), but it does unblock us right now. For the postgresql binary specifically, I have checked that the three mirrors give me the exact same file between them, and that it matches the old hash. For the other files, I downloaded them from the primary mirror ([repo.msys2.org]) and checked that the hashes match the recorded values in our JSON manifest. CHANGELOG_BEGIN CHANGELOG_END [mirrors.piconets.webwerks.in]: https://mirrors.piconets.webwerks.in/msys2-mirror/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [mirrors.aliyun.com]: https://mirrors.aliyun.com/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst?spm=a2c6h.25603864.0.0.32b23240Qp8jCL [mirror.iscas.ac.cn]: https://mirror.iscas.ac.cn/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [repo.msys2.org]: https://repo.msys2.org/mingw/x86_64/
Today the postgresql 12.4 artifacts were purged from the msys2 primary mirrors. I was able to find a copy on some old mirrors (I downloaded from [mirrors.piconets.webwerks.in], [mirrors.aliyun.com], and [mirror.iscas.ac.cn]), but that raised the question of where to put the binary so our CI nodes can access it. I decided to put it on one of our GCS buckets, and while I was there I did the whole msys2 set of packages. Does this manually may not be the best path forward for a long-term solution (though maybe it is; they tend not to change all that often), but it does unblock us right now. For the postgresql binary specifically, I have checked that the three mirrors give me the exact same file between them, and that it matches the old hash. For the other files, I downloaded them from the primary mirror ([repo.msys2.org]) and checked that the hashes match the recorded values in our JSON manifest. CHANGELOG_BEGIN CHANGELOG_END [mirrors.piconets.webwerks.in]: https://mirrors.piconets.webwerks.in/msys2-mirror/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [mirrors.aliyun.com]: https://mirrors.aliyun.com/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst?spm=a2c6h.25603864.0.0.32b23240Qp8jCL [mirror.iscas.ac.cn]: https://mirror.iscas.ac.cn/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [repo.msys2.org]: https://repo.msys2.org/mingw/x86_64/
* dev-env: pin msys2/mingw Today the postgresql 12.4 artifacts were purged from the msys2 primary mirrors. I was able to find a copy on some old mirrors (I downloaded from [mirrors.piconets.webwerks.in], [mirrors.aliyun.com], and [mirror.iscas.ac.cn]), but that raised the question of where to put the binary so our CI nodes can access it. I decided to put it on one of our GCS buckets, and while I was there I did the whole msys2 set of packages. Does this manually may not be the best path forward for a long-term solution (though maybe it is; they tend not to change all that often), but it does unblock us right now. For the postgresql binary specifically, I have checked that the three mirrors give me the exact same file between them, and that it matches the old hash. For the other files, I downloaded them from the primary mirror ([repo.msys2.org]) and checked that the hashes match the recorded values in our JSON manifest. CHANGELOG_BEGIN CHANGELOG_END [mirrors.piconets.webwerks.in]: https://mirrors.piconets.webwerks.in/msys2-mirror/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [mirrors.aliyun.com]: https://mirrors.aliyun.com/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst?spm=a2c6h.25603864.0.0.32b23240Qp8jCL [mirror.iscas.ac.cn]: https://mirror.iscas.ac.cn/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [repo.msys2.org]: https://repo.msys2.org/mingw/x86_64/
Today the postgresql 12.4 artifacts were purged from the msys2 primary mirrors. I was able to find a copy on some old mirrors (I downloaded from [mirrors.piconets.webwerks.in], [mirrors.aliyun.com], and [mirror.iscas.ac.cn]), but that raised the question of where to put the binary so our CI nodes can access it. I decided to put it on one of our GCS buckets, and while I was there I did the whole msys2 set of packages. Does this manually may not be the best path forward for a long-term solution (though maybe it is; they tend not to change all that often), but it does unblock us right now. For the postgresql binary specifically, I have checked that the three mirrors give me the exact same file between them, and that it matches the old hash. For the other files, I downloaded them from the primary mirror ([repo.msys2.org]) and checked that the hashes match the recorded values in our JSON manifest. CHANGELOG_BEGIN CHANGELOG_END [mirrors.piconets.webwerks.in]: https://mirrors.piconets.webwerks.in/msys2-mirror/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [mirrors.aliyun.com]: https://mirrors.aliyun.com/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst?spm=a2c6h.25603864.0.0.32b23240Qp8jCL [mirror.iscas.ac.cn]: https://mirror.iscas.ac.cn/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [repo.msys2.org]: https://repo.msys2.org/mingw/x86_64/
* dev-env: pin msys2/mingw Today the postgresql 12.4 artifacts were purged from the msys2 primary mirrors. I was able to find a copy on some old mirrors (I downloaded from [mirrors.piconets.webwerks.in], [mirrors.aliyun.com], and [mirror.iscas.ac.cn]), but that raised the question of where to put the binary so our CI nodes can access it. I decided to put it on one of our GCS buckets, and while I was there I did the whole msys2 set of packages. Does this manually may not be the best path forward for a long-term solution (though maybe it is; they tend not to change all that often), but it does unblock us right now. For the postgresql binary specifically, I have checked that the three mirrors give me the exact same file between them, and that it matches the old hash. For the other files, I downloaded them from the primary mirror ([repo.msys2.org]) and checked that the hashes match the recorded values in our JSON manifest. CHANGELOG_BEGIN CHANGELOG_END [mirrors.piconets.webwerks.in]: https://mirrors.piconets.webwerks.in/msys2-mirror/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [mirrors.aliyun.com]: https://mirrors.aliyun.com/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst?spm=a2c6h.25603864.0.0.32b23240Qp8jCL [mirror.iscas.ac.cn]: https://mirror.iscas.ac.cn/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [repo.msys2.org]: https://repo.msys2.org/mingw/x86_64/
* dev-env: pin msys2/mingw Today the postgresql 12.4 artifacts were purged from the msys2 primary mirrors. I was able to find a copy on some old mirrors (I downloaded from [mirrors.piconets.webwerks.in], [mirrors.aliyun.com], and [mirror.iscas.ac.cn]), but that raised the question of where to put the binary so our CI nodes can access it. I decided to put it on one of our GCS buckets, and while I was there I did the whole msys2 set of packages. Does this manually may not be the best path forward for a long-term solution (though maybe it is; they tend not to change all that often), but it does unblock us right now. For the postgresql binary specifically, I have checked that the three mirrors give me the exact same file between them, and that it matches the old hash. For the other files, I downloaded them from the primary mirror ([repo.msys2.org]) and checked that the hashes match the recorded values in our JSON manifest. CHANGELOG_BEGIN CHANGELOG_END [mirrors.piconets.webwerks.in]: https://mirrors.piconets.webwerks.in/msys2-mirror/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [mirrors.aliyun.com]: https://mirrors.aliyun.com/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst?spm=a2c6h.25603864.0.0.32b23240Qp8jCL [mirror.iscas.ac.cn]: https://mirror.iscas.ac.cn/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [repo.msys2.org]: https://repo.msys2.org/mingw/x86_64/
* dev-env: pin msys2/mingw Today the postgresql 12.4 artifacts were purged from the msys2 primary mirrors. I was able to find a copy on some old mirrors (I downloaded from [mirrors.piconets.webwerks.in], [mirrors.aliyun.com], and [mirror.iscas.ac.cn]), but that raised the question of where to put the binary so our CI nodes can access it. I decided to put it on one of our GCS buckets, and while I was there I did the whole msys2 set of packages. Does this manually may not be the best path forward for a long-term solution (though maybe it is; they tend not to change all that often), but it does unblock us right now. For the postgresql binary specifically, I have checked that the three mirrors give me the exact same file between them, and that it matches the old hash. For the other files, I downloaded them from the primary mirror ([repo.msys2.org]) and checked that the hashes match the recorded values in our JSON manifest. CHANGELOG_BEGIN CHANGELOG_END [mirrors.piconets.webwerks.in]: https://mirrors.piconets.webwerks.in/msys2-mirror/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [mirrors.aliyun.com]: https://mirrors.aliyun.com/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst?spm=a2c6h.25603864.0.0.32b23240Qp8jCL [mirror.iscas.ac.cn]: https://mirror.iscas.ac.cn/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [repo.msys2.org]: https://repo.msys2.org/mingw/x86_64/
- update GPG key docs - remove `check_changelog_entry` job. - ensure we have all tags available when running `check-protobuf-stability.sh`. - fix scalafmt coursier deps - fix daml-binaries URL (deleted DNS) - Add yarn lock file for build-and-lint-test (#15727) (#15897) - add yarn lock file - file--frozen-lockfile - dev-env: pin msys2/mingw (#15311) - fix build-and-lint (#13879)
* dev-env: pin msys2/mingw Today the postgresql 12.4 artifacts were purged from the msys2 primary mirrors. I was able to find a copy on some old mirrors (I downloaded from [mirrors.piconets.webwerks.in], [mirrors.aliyun.com], and [mirror.iscas.ac.cn]), but that raised the question of where to put the binary so our CI nodes can access it. I decided to put it on one of our GCS buckets, and while I was there I did the whole msys2 set of packages. Does this manually may not be the best path forward for a long-term solution (though maybe it is; they tend not to change all that often), but it does unblock us right now. For the postgresql binary specifically, I have checked that the three mirrors give me the exact same file between them, and that it matches the old hash. For the other files, I downloaded them from the primary mirror ([repo.msys2.org]) and checked that the hashes match the recorded values in our JSON manifest. CHANGELOG_BEGIN CHANGELOG_END [mirrors.piconets.webwerks.in]: https://mirrors.piconets.webwerks.in/msys2-mirror/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [mirrors.aliyun.com]: https://mirrors.aliyun.com/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst?spm=a2c6h.25603864.0.0.32b23240Qp8jCL [mirror.iscas.ac.cn]: https://mirror.iscas.ac.cn/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [repo.msys2.org]: https://repo.msys2.org/mingw/x86_64/
Also, get branch to build: - remove `check_changelog_entry` job. - ensure we have all tags available when running `check-protobuf-stability.sh`. - fix scalafmt coursier deps - fix daml-binaries URL (deleted DNS) - dev-env: pin msys2/mingw (#15311) - Add yarn lock file for build-and-lint-test (#15727) (#15897)
* dev-env: pin msys2/mingw Today the postgresql 12.4 artifacts were purged from the msys2 primary mirrors. I was able to find a copy on some old mirrors (I downloaded from [mirrors.piconets.webwerks.in], [mirrors.aliyun.com], and [mirror.iscas.ac.cn]), but that raised the question of where to put the binary so our CI nodes can access it. I decided to put it on one of our GCS buckets, and while I was there I did the whole msys2 set of packages. Does this manually may not be the best path forward for a long-term solution (though maybe it is; they tend not to change all that often), but it does unblock us right now. For the postgresql binary specifically, I have checked that the three mirrors give me the exact same file between them, and that it matches the old hash. For the other files, I downloaded them from the primary mirror ([repo.msys2.org]) and checked that the hashes match the recorded values in our JSON manifest. CHANGELOG_BEGIN CHANGELOG_END [mirrors.piconets.webwerks.in]: https://mirrors.piconets.webwerks.in/msys2-mirror/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [mirrors.aliyun.com]: https://mirrors.aliyun.com/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst?spm=a2c6h.25603864.0.0.32b23240Qp8jCL [mirror.iscas.ac.cn]: https://mirror.iscas.ac.cn/msys2/mingw/x86_64/mingw-w64-x86_64-postgresql-12.4-1-any.pkg.tar.zst [repo.msys2.org]: https://repo.msys2.org/mingw/x86_64/
- remove `check_changelog_entry` job. - ensure we have all tags available when running `check-protobuf-stability.sh`. - fix scalafmt coursier deps - fix copyright notice - dev-env: pin msys2/mingw (#15311) - fix da-ghc-lib caching - re-pin da-ghc-lib - Add yarn lock file for build-and-lint-test (#15727) (#15897)
Today the postgresql 12.4 artifacts were purged from the msys2 primary mirrors. I was able to find a copy on some old mirrors (I downloaded from mirrors.piconets.webwerks.in, mirrors.aliyun.com, and mirror.iscas.ac.cn), but that raised the question of where to put the binary so our CI nodes can access it. I decided to put it on one of our GCS buckets, and while I was there I did the whole msys2 set of packages.
Does this manually may not be the best path forward for a long-term solution (though maybe it is; they tend not to change all that often), but it does unblock us right now.
For the postgresql binary specifically, I have checked that the three mirrors give me the exact same file between them, and that it matches the old hash. For the other files, I downloaded them from the primary mirror (repo.msys2.org) and checked that the hashes match the recorded values in our JSON manifest.
CHANGELOG_BEGIN
CHANGELOG_END