Conversation
| $(package)_version=2.1.7 | ||
| $(package)_download_path=https://github.com/libevent/libevent/archive/ | ||
| $(package)_file_name=release-$($(package)_version)-rc.tar.gz | ||
| $(package)_sha256_hash=548362d202e22fe24d4c3fad38287b4f6d683e6c21503341373b89785fa6f991 |
There was a problem hiding this comment.
Minor note: This hash is not guaranteed to be constant, I think.
There was a problem hiding this comment.
Hm but not checking the hash at all would not be acceptable.
There was a problem hiding this comment.
Of course, but we need to keep a backup of the GitHub generated zip file. (Which reminds me we already do so on bitcoincore.org/)
There was a problem hiding this comment.
I may be off track, but if the hash changes for the given release, doesn't that mean we WANT the build system to explode in everyone's faces so people react? I can only imagine a hash change for the same package version would be due to some serious issue being hot-fixed upstream. Keeping and using a backup would mean that hot-fix goes unnoticed.
There was a problem hiding this comment.
I can only imagine a hash change for the same package version would be due to some serious issue being hot-fixed upstream
This would require a new release of libevent. What I was referring to, is that the hash changes after GitHub purges its caches for zipped downloads of git tags/commits. (Note the above zip is not provided/signed by libevent but generated by GitHub for convenience.) I could image that GitHub does not deterministically generate zips.
There was a problem hiding this comment.
@MarcoFalke I remember dealing with this at one point already, and I seem to remember github fixing the downloads to be deterministic, but I can't find any reference to that now.
It looks like our native_cctools comes from a similar link, so I assume that we would've noticed new hashes by now.
@kallewoof You're very much on-track. The issue (if I recall) is that github always serves the same .tar, but the gzipped result can change if it's been regenerated.
There was a problem hiding this comment.
Wouldn't it be possible to have a checksum check for the decompressed .tar then?
There was a problem hiding this comment.
@sipa Sure, if that's necessary. Given that we have similar downloads atm that aren't causing issues though, I suspect this is no longer an issue.
There was a problem hiding this comment.
Let's just take the chance then and merge this.
|
Is there any reason this still has a WIP tag? |
|
@laanwj Really only due to the URL uncertainty. However we can update to a more stable URL in future if needed. |
|
Agree with @fanquake |
8217bd1 [depends] libevent 2.1.7rc (fanquake)
|
utACK 8217bd1. I'm not worried about the URL. |
|
post-merge Concept ACK |
| $(package)_patches=reuseaddr.patch libevent-2-fixes.patch | ||
| $(package)_version=2.1.7 | ||
| $(package)_download_path=https://github.com/libevent/libevent/archive/ | ||
| $(package)_file_name=release-$($(package)_version)-rc.tar.gz |
There was a problem hiding this comment.
Looks like they just released the stable version, so we could use that, maybe.
There was a problem hiding this comment.
That's annoying, we delay this update for months in the expectation that there will be a new stable version any time, and after we merge this there suddenly it is, the new stable version.
libevent-based http server Cherry-picked from the following upstream PRs: - bitcoin/bitcoin#5677 - bitcoin/bitcoin#6695 - bitcoin/bitcoin#6899 - bitcoin/bitcoin#7016 - bitcoin/bitcoin#7964 - bitcoin/bitcoin#8722 - bitcoin/bitcoin#8730 - bitcoin/bitcoin#9073 - bitcoin/bitcoin#9265 - bitcoin/bitcoin#9387 - bitcoin/bitcoin#9471 - bitcoin/bitcoin#9647 - bitcoin/bitcoin#9903 Closes #1593 and #1856.
libevent-based http server Cherry-picked from the following upstream PRs: - bitcoin/bitcoin#5677 - bitcoin/bitcoin#6695 - bitcoin/bitcoin#6899 - bitcoin/bitcoin#7016 - bitcoin/bitcoin#7964 - bitcoin/bitcoin#8722 - bitcoin/bitcoin#8730 - bitcoin/bitcoin#9073 - bitcoin/bitcoin#9265 - bitcoin/bitcoin#9387 - bitcoin/bitcoin#9471 - bitcoin/bitcoin#9647 - bitcoin/bitcoin#9903 - bitcoin/bitcoin#6640 - bitcoin/bitcoin#8139 - bitcoin/bitcoin#8839 Closes #1593 and #1856.
7 participants
See #8867 for discussion around moving to libevent 2.1.x .
We can drop both of our patches with the switch to the 2.1.x branch.
The libevent-2-fixes patch (#8730), was already included in the 2.1.6beta release, so can be removed.
The reuseaddr patch was introduced here. Looking through the 2.17 code, it looks like it might have been a backport from the 2.1.x branch, and so can also be dropped.
libevent 2.1.7-rc changelog
Closes #8867