You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Over the last ~2 days, the JFrog Boost repository was down/slow-to-respond and caused significant disruption to the whole React Native ecosystem (iOS apps could not build due to failing CocoaPods installation, Android CI was broken, etc.)
I've seen that your official website now recommends to use https://archives.boost.io/ instead of the JFrog repository.
I'm wondering where is https://archives.boost.io/ hosted. Is it going to be maintained long term or is it just a temporary measure while JFrog was down?
We're considering moving our download URL to point to https://archives.boost.io/ but we're wondering if this is now the recommended repository where to download Boost sources from:
At this moment, the preferred choice is JFrog. The boost website ought to reflect that soon.
However...
We hope to switch the JFrog hosting to use a Fastly CDN because they are concerned about the amount of bandwidth. When that happens the download links will change again.
At this moment, the preferred choice is JFrog. The boost website ought to reflect that soon.
However...
We hope to switch the JFrog hosting to use a Fastly CDN because they are concerned about the amount of bandwidth. When that happens the download links will change again.
Thanks for the clarification. Will there be an announcement or should we just check the download link regularly?
We're likely going to do the same for boost in the coming days so that our CI is no longer dependent on archives with flaky uptime. I will update here when it is done. If the boost maintainers like to take ownership of this - now or in the future - we're very much open to that. We do not seek to have this as our responsibility, anyways, and are more than happy to migrate it to the boost organisation.
For the moderators: if this is not the right location to post this, feel free to move and/or request me to post somewhere else.
We're likely going to do the same for boost in the coming days so that our CI is no longer dependent on archives with flaky uptime. I will update here when it is done. If the boost maintainers like to take ownership of this - now or in the future - we're very much open to that. We do not seek to have this as our responsibility, anyways, and are more than happy to migrate it to the boost organisation.
For the moderators: if this is not the right location to post this, feel free to move and/or request me to post somewhere else.
FYI: due to the latest release resulting in issues in our pipeline again (1.87.0 was available for some platforms but not for all of them), we have finally decided to implement the solution proposed in the above comment in https://github.com/PowerGridModel/boost-pypi (note: the conda-forge version of libboost-headers was not sufficient for us; I can elaborate further if needed but it basically amounts to not every Python end user having conda available). The library uploads a repackaged version of only the headers in the brew packaged version of boost to https://pypi.org/project/libboost-headers/.
For moderators or admins of Boost: we are more than willing to donate this project to you. Please contact us if you are open to that.
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://archives.boost.io/release/1.87.0/source/boost_1_87_0.tar.gz
It should be possible to take various steps to troubleshoot. The first one, I modified the Fastly VCL configuration to cache 404s for 10 mins. Not the "default" time period which is 1 hr, or the quite long (a month) for archive zip files. Let's see how this goes, please report back errors.
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://archives.boost.io/release/1.87.0/source/boost_1_87_0.tar.gz
It should be possible to take various steps to troubleshoot. The first one, I modified the Fastly VCL configuration to cache 404s for 10 mins. Not the "default" time period which is 1 hr, or the quite long (a month) for archive zip files. Let's see how this goes, please report back errors.
Our main issue is that we do not have the capacity to debug. It's good that this may solve the error, but we did get the 404 over the course of several hours (first noticed Thursday 2:45PM UTC+1, and again/still Friday 8:30AM UTC+1), so I don't think caching is the only issue.
Anyways, we now migrated to the alternative solution, which pretty well suits our use case of having it as a build-dependency for the C/C++ core of our Python package.
@mgovers the traffic levels on the download are significant, in the TBs per day, which is the reason we have preferred to use a CDN (Fastly) and not shift the burden to possibly unsuspecting hosting services, pypi or even github, although both of those organizations may be equipped to handle the bandwidth load. "again/still Friday 8:30AM UTC". ok, that time was still before the most recent update.
@mgovers the traffic levels on the download are significant, in the TBs per day, which is the reason we have preferred to use a CDN (Fastly) and not shift the burden to possibly unsuspecting hosting services, pypi or even github, although both of those organizations may be equipped to handle the bandwidth load. "again/still Friday 8:30AM UTC". ok, that time was still before the most recent update.
Thank you again for the reply. I understand your point and I did not know about the most recent update. We'll have to discuss amongst ourselves whether to migrate back or to keep it as is, as we were thinking of migrating away from the intermediate downloader (pybuild-header-dependency) anyways. I will keep you up to date.
Activity
sdarwin commentedon Jan 2, 2024
The original jfrog links should be re-activated and working now. It was a mistake on their end.
(archives.boost.io used a major cloud cdn)
cortinico commentedon Jan 3, 2024
Thanks for the clarification @sdarwin
I'm wondering what is the recommended source from now on. Should React Native users download from archives.boost.io or from JFrog?
sdarwin commentedon Jan 3, 2024
At this moment, the preferred choice is JFrog. The boost website ought to reflect that soon.
However...
We hope to switch the JFrog hosting to use a Fastly CDN because they are concerned about the amount of bandwidth. When that happens the download links will change again.
cortinico commentedon Jan 3, 2024
Thanks for the clarification. Will there be an announcement or should we just check the download link regularly?
sdarwin commentedon Jan 3, 2024
Hoping to enable the new downloads within the next week if possible, but not guaranteed. At least, check the main website.
cortinico commentedon Jan 8, 2024
@sdarwin we're back with JFrog being down. Any official updates on your end? Should we move everyone to archives.boost.io?
mgovers commentedon Jan 10, 2024
The PowerGridModel/power-grid-model moved to https://archives.boost.io/ but it also appears to be flaky. Restarting our CI once or twice does fix the issue, but it's not really the optimal solution.
We've had similar issues before with
nlohmann-jsonandmsgpack-cxxand decided to push the packaged files to PyPI (see https://github.com/PowerGridModel/nlohmann-json-pypi/tree/main and https://github.com/PowerGridModel/msgpack-cxx-pypi). PyPI has a good track record in terms of availability and is completely free for open source projects and is great for us because we're creating a Python package, anyways.We're likely going to do the same for
boostin the coming days so that our CI is no longer dependent on archives with flaky uptime. I will update here when it is done. If the boost maintainers like to take ownership of this - now or in the future - we're very much open to that. We do not seek to have this as our responsibility, anyways, and are more than happy to migrate it to the boost organisation.For the moderators: if this is not the right location to post this, feel free to move and/or request me to post somewhere else.
mgovers commentedon Dec 13, 2024
FYI: due to the latest release resulting in issues in our pipeline again (1.87.0 was available for some platforms but not for all of them), we have finally decided to implement the solution proposed in the above comment in https://github.com/PowerGridModel/boost-pypi (note: the
conda-forgeversion oflibboost-headerswas not sufficient for us; I can elaborate further if needed but it basically amounts to not every Python end user having conda available). The library uploads a repackaged version of only the headers in thebrewpackaged version ofboostto https://pypi.org/project/libboost-headers/.For moderators or admins of Boost: we are more than willing to donate this project to you. Please contact us if you are open to that.
sdarwin commentedon Dec 13, 2024
Hi @mgovers ,
Thanks for the comment!
The new download URL is at https://archives.boost.io/ . I see in github actions you hit this error.
It should be possible to take various steps to troubleshoot. The first one, I modified the Fastly VCL configuration to cache 404s for 10 mins. Not the "default" time period which is 1 hr, or the quite long (a month) for archive zip files. Let's see how this goes, please report back errors.
mgovers commentedon Dec 16, 2024
Hi @sdarwin ,
Thank you for your feedback
Our main issue is that we do not have the capacity to debug. It's good that this may solve the error, but we did get the 404 over the course of several hours (first noticed Thursday 2:45PM UTC+1, and again/still Friday 8:30AM UTC+1), so I don't think caching is the only issue.
Anyways, we now migrated to the alternative solution, which pretty well suits our use case of having it as a
build-dependencyfor the C/C++ core of our Python package.sdarwin commentedon Dec 16, 2024
@mgovers the traffic levels on the download are significant, in the TBs per day, which is the reason we have preferred to use a CDN (Fastly) and not shift the burden to possibly unsuspecting hosting services, pypi or even github, although both of those organizations may be equipped to handle the bandwidth load. "again/still Friday 8:30AM UTC". ok, that time was still before the most recent update.
mgovers commentedon Dec 16, 2024
Hi @sdarwin ,
Thank you again for the reply. I understand your point and I did not know about the most recent update. We'll have to discuss amongst ourselves whether to migrate back or to keep it as is, as we were thinking of migrating away from the intermediate downloader (
pybuild-header-dependency) anyways. I will keep you up to date.[legacy] boost: Update download URL
[legacy] boost: Update download URL
Deps: Update Boost library download URL
[legacy] boost: Update download URL
[legacy] boost: Update download URL
[legacy] boost: Update download URL
[legacy] boost: Update download URL
[legacy] boost: Update download URL
[legacy] boost: Update download URL
Deps: Update Boost library download URL
Deps: Update Boost library download URL
Fix boost download url
Switch to the officially recommended CDN