Age | Commit message (Collapse) | Author |
|
error: unknown switch `a'
usage: git add [<options>] [--] <pathspec>...
-n, --dry-run dry run
-v, --verbose be verbose
-i, --interactive interactive picking
-p, --patch select hunks interactively
-e, --edit edit current diff and apply
-f, --force allow adding otherwise ignored files
-u, --update update tracked files
--renormalize renormalize EOL of tracked files (implies -u)
-N, --intent-to-add record only the fact that the path will be added later
-A, --all add changes from all tracked and untracked files
--ignore-removal ignore paths removed in the working tree (same as --no-all)
--refresh don't add, only refresh the index
--ignore-errors just skip files which cannot be added because of errors
--ignore-missing check if - even missing - files are ignored in dry run
--chmod (+|-)x override the executable bit of the listed files
|
|
Also fixes a link to the macdeploy instructions.
|
|
|
|
fab2f351f2311295c9ed893fe883a08a9104144e doc: Update release process with latest changes (MarcoFalke)
Pull request description:
Mainly adding the reminder to bump the flatpak
ACKs for top commit:
laanwj:
ACK fab2f351f2311295c9ed893fe883a08a9104144e
fanquake:
ACK fab2f351f2311295c9ed893fe883a08a9104144e
Tree-SHA512: fe279a6cdee881e8dd608cb7d09d992c4b668b01b9d0d2dbfaf92f12f3032b8fcb2c256b20fcee861397451add1338f162b6e5fa7b3c21e76c247cc419315284
|
|
|
|
|
|
The original osslsigncode project (https://sourceforge.net/projects/osslsigncode/) has been marked as abandonware,
"This is now - and has been for a long while - abandonware. Feel free to create your own forks etc.".
However, a fork at https://github.com/mtrojnar/osslsigncode has emerged that has incorporated
theuni's patches, updated the tool to work with OpenSSL 1.1 and made other improvements.
This commit switches the windows signer descriptor to use this new version of osslsigncode.
|
|
Can be reviewed with the git diff option
--color-moved=dimmed-zebra
|
|
fa3a7331160d1a460b1c15fca1810e98070d629c chainparams: Bump assumed chain params (MarcoFalke)
Pull request description:
As every year, reviewers get extra point when their node is running:
* `assumevalid=0`
* `checkpoints=0`
* on non-x86_64 hardware
See https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#before-every-major-and-minor-release for the process.
ACKs for top commit:
laanwj:
ACK fa3a7331160d1a460b1c15fca1810e98070d629c
Sjors:
ACK fa3a7331160d1a460b1c15fca1810e98070d629c for mainnet on macOS 10.14.6.
jamesob:
ACK https://github.com/bitcoin/bitcoin/pull/17002/commits/fa3a7331160d1a460b1c15fca1810e98070d629c
fanquake:
ACK fa3a7331160d1a460b1c15fca1810e98070d629c - checked the mainnet values. I have notes on reviewing `assumevalid` updates in [core-review](https://github.com/fanquake/core-review/blob/master/update-assumevalid.md).
Tree-SHA512: fc545ba0a7056908040b47076b393d028c1c022967c25a2074752f76f0386ef099a64445da6125117a04418bd7eb0655121bfc94e6f60b7bc2666947491b5228
|
|
|
|
|
|
variables to release process
eb4c43e49f625895670866b89bb56ca641c4eeb7 doc: documents how to calculate m_assumed_blockchain_size and m_assumed_chain_state_size on the release process. (marcoagner)
Pull request description:
Regarding [this](https://github.com/bitcoin/bitcoin/pull/15183#issuecomment-463133734) on https://github.com/bitcoin/bitcoin/pull/15183.
Added an "Additional information" section for this which seems reasonable to me but may not be the best place for this. Also, let me know if anything else should be documented here (like more details).
ACKs for top commit:
laanwj:
ACK eb4c43e49f625895670866b89bb56ca641c4eeb7
Tree-SHA512: 7e6fc46740daa01dd9be5a8da7846e7a9f7fa866bf31fdc2cb252f90c698cfd6ef954f9588f7abcebda2355ec2b2a380635e14a164e53e77d38abefa3e2cc698
|
|
|
|
|
|
The riscv64 binary is created by the Gitian scripts and distributed by the
Bitcoin Core website, so it should be listed in the release process docs.
|
|
and reorganise the section and add relative url links.
Follow-up to e47dc4f.
|
|
- Create a release notes draft wiki for collaborative editing at https://github.com/bitcoin-core/bitcoin-devwiki/wiki as seen for releases 0.17.0 and 0.18.0.
- As per http://www.erisian.com.au/bitcoin-core-dev/log-2019-03-28.html#l-342, for the period during which the notes are being edited on the wiki, the version on the branch should be wiped and replaced with a link to the wiki which should be used for all announcements until final.
- Before final, remove the "Needs release note" label from relevant PRs/issues and merge the release notes from the wiki into the branch.
- Create a pinned meta-issue dedicated to testing the release candidate and communicate it in release announcements where useful. The former is done in practice (e.g. #15555, #14902) and the latter addresses the discussion here: https://x0f.org/web/statuses/101753569204220416.
- Adapt and merge the updates in https://github.com/bitcoin/bitcoin/pull/15692.
- Update the version numbers in all the examples.
- Reorganise the headers in the Branch Updates section.
|
|
|
|
|
|
|
|
m_assumed_chain_state_size on the release process.
|
|
|
|
|
|
03b8596dd665d2f70c917794295911adb8680bcc Add checksum in gitian build scripts for ossl (TheCharlatan)
Pull request description:
This adds a checksum in the gitian build script to make sure that ossl tool and theuni's patch matches what is expected. Also changes the url to use https.
Tree-SHA512: bd25acda1c7d9ca94e710bdfa915d20810101e10b0c68913a00fcb0eada25cdc2d59f7efebc822e07dea7eaab058024e6c53031883ded0ecf9f08212e50a25b3
|
|
9d0e52834 implements different disk sizes for different networks on intro (marcoagner)
Pull request description:
Fixes https://github.com/bitcoin/bitcoin/issues/13213.
Mostly, I layed out the concept to open the PR for refinement and getting feedback if the approach is okay. Changes are expected.
Two points:
- The values for both new consts `TESTNET_BLOCK_CHAIN_SIZE` and `TESTNET_CHAIN_STATE_SIZE` is certainly not optimal; I just checked the size of my testnet3 related dirs and set them to little bit higher values. Which values should be used?
- Should we do something like this to regtest? Or these "niceties" do not matter when on regtest?
Thanks!
Tree-SHA512: 8ae87a29fa8356b899e7a823c76cde793d9126b4ee59554d7a2a8edb088fe42a19976b34c06c2fd4a98a727e1e4971dd983f42b6093ea6caa255b45004e22bb4
|
|
This adds a checksum in the gitian build script to make sure that
ossl tool and theuni's patch matches what is expected. Also changes
the url to use https and adds the same instructions to the release docs.
|
|
|
|
|
|
- Creates m_assumed_blockchain_size and m_assumed_chain_state_size on CChainParams.
- Implements access to CChainParams' m_assumed_blockchain_size and m_assumed_chain_state_size on node interface.
- Implements m_assumed_blockchain_size and m_assumed_chain_state_size on qt/intro via node interface.
- Updates release process document with the new CChainParam's values.
|
|
|
|
- Remove dependency on sed (sed was overkill when you can just add plain
text to the git log --format command)
- Sort resulting list of authors alphabetically (case-insensitive)
- Provide an example of how to only generate authors between versions
|
|
|
|
|
|
|
|
|
|
Gitian fails to perform downloads right now on my set up. This can be circumvented by first checking out the tag being built and then doing the depends download step before running `gbuild`.
|
|
SIGNER can contains space inside now. mentioned in https://github.com/bitcoin/bitcoin/pull/12527#issuecomment-370506416
|
|
fabb72b contrib: Remove xpired 522739F6 key (MarcoFalke)
faeab66 contrib: Replace developer keys with list of pgp fingerprints (MarcoFalke)
Pull request description:
Having to host a copy of the keys in this repo was a common source of discussion and distraction, caused by problems such as:
* Outdated keys. Unclear whether and when to replace by fresh copies.
* Unclear when to add a key of a new developer or Gitian builder.
The problems are solved by
* Having no keys but only the fingerprints
* Adding a rule of thumb, when to add a new key
<strike>Moving the keys to a different repo solves none of these issues, but since the keys are not bound to releases or git branches of Bitcoin Core, they should live somewhere else.
Obviously, all keys are hosted and distributed on key servers, but were added to the repo solely for convenience and redundancy.
Moving the mirror of those keys to a different repo makes it less distracting to update them -- let's say -- prior to every major release.
I updated our `doc/release-process.md` to reflect the new location.
DEPENDS_ON https://github.com/bitcoin-core/gitian.sigs/pull/621
</strike>
Tree-SHA512: c00795a07603190e26dc4526f6ce11e492fb048dc7ef54b38f859b77dcde25f58ec4449f5cf3f85a5e9c2dd2743bde53f7ff03c8eccf0d75d51784a6b164e47d
|
|
7444149 Document method for reviewers to verify chainTxData (John Newbery)
Pull request description:
This commit adds the final block hash of the window to getchaintxstats
and documents how reviewers can verify changes to chainTxData.
Tree-SHA512: d16abb5f47d058e52660f4d495f1e453205b1b83716d7c810ff62a70338db721386c1808ec1fc8468f514e4d80cc58e3c96eeb3184cbbcb1d07830fa5e53f342
|
|
This commit adds the final block hash of the window to getchaintxstats
and documents how reviewers can verify changes to chainTxData.
|
|
1340eda3b7 Fix typos (practicalswift)
Pull request description:
Fix typos.
Tree-SHA512: 533a136831387ef26e9a74ba078437496bee38cc026da73fa9e6f6e7f4d5665eccac24cf3ef05e6d3af1329a1214f5ce71b039ddb8378b074e6d4408b8701f95
|
|
Adds a short explanation how to update chainTxData to the release
process. Mention where to get the data, and link to an example.
|
|
|
|
|
|
|
|
|
|
41b8821 Add updating of chainTxData to release process (Pieter Wuille)
Tree-SHA512: f7d6e72b19aa83fc4851a9316d6c6a236e0e914d637525cda42c0b15a94543b8072ce67b57d6b12141332a03b64b6c715dff4d61e6e58e0197b22305b35ad65d
|
|
09fe2d9 release: update docs to show basic codesigning procedure (Cory Fields)
f642753 release: create a bundle for the new signing script (Cory Fields)
0068361 release: add win detached sig creator and our cert chain (Cory Fields)
Tree-SHA512: 032ad84697c70faaf857b9187f548282722cffca95d658e36413dc048ff02d9183253373254ffcc1158afb71140753f35abfc9fc8781ea5329c04d13c98759c0
|
|
|
|
This disentangles the script validation skipping from checkpoints.
A new option is introduced "assumevalid" which specifies a block whos
ancestors we assume all have valid scriptsigs and so we do not check
them when they are also burried under the best header by two weeks
worth of work.
Unlike checkpoints this has no influence on consensus unless you set
it to a block with an invalid history. Because of this it can be
easily be updated without risk of influencing the network consensus.
This results in a massive IBD speedup.
This approach was independently recommended by Peter Todd and Luke-Jr
since POW based signature skipping (see PR#9180) does not have the
verifiable properties of a specific hash and may create bad incentives.
The downside is that, like checkpoints, the defaults bitrot and older
releases will sync slower. On the plus side users can provide their
own value here, and if they set it to something crazy all that will
happen is more time will be spend validating signatures.
Checkblocks and checklevel are also moved to the hidden debug options:
Especially now that checkblocks has a low default there is little need
to change these settings, and users frequently misunderstand them as
influencing security or IBD speed. By hiding them we offset the
space added by this new option.
|