mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=tor-dirmgr-v0.5.1 2022-06-24T17:31:38Z 2022-06-24T17:31:38Z Nick Mathewson nickm@torproject.org 2022-06-24T17:31:38Z urn:sha1:1dda69af2b102b72c149503b49f7e598a8f8af5e 2022-06-24T16:00:22Z Nick Mathewson nickm@torproject.org 2022-06-24T16:00:22Z urn:sha1:20435aea751331817709acde8d4b65b5fb8d8f12 These were done with the following commands: ``` cargo set-version -p tor-basic-utils --bump patch cargo set-version -p fs-mistrust --bump minor cargo set-version -p tor-error --bump patch cargo set-version -p tor-config --bump patch cargo set-version -p tor-units --bump patch cargo set-version -p tor-rtcompat --bump minor cargo set-version -p tor-llcrypto --bump patch cargo set-version -p tor-bytes --bump minor cargo set-version -p tor-socksproto --bump minor cargo set-version -p tor-cert --bump minor cargo set-version -p tor-cell --bump minor cargo set-version -p tor-proto --bump minor cargo set-version -p tor-netdoc --bump patch cargo set-version -p tor-netdir --bump minor cargo set-version -p tor-persist --bump patch cargo set-version -p tor-chanmgr --bump minor cargo set-version -p tor-guardmgr --bump minor cargo set-version -p tor-circmgr --bump patch cargo set-version -p tor-dirclient --bump patch cargo set-version -p tor-dirmgr --bump minor cargo set-version -p arti-client --bump patch cargo set-version -p arti --bump minor cargo set-version -p arti-bench --bump minor cargo set-version -p arti-testing --bump minor ``` 2022-06-24T14:13:58Z Ian Jackson iwj@torproject.org 2022-06-24T14:13:58Z urn:sha1:4831f9d38c8b3599184ca5f93a9929f784c8026b Fix clippy nightly again See merge request tpo/core/arti!603 2022-06-23T18:15:42Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-06-23T18:15:29Z urn:sha1:589c6e52bb49ccfe6c0ad9d18d6b994978e46c6c Update all lint blocks 2022-06-23T12:58:25Z Nick Mathewson nickm@torproject.org 2022-06-23T12:58:25Z urn:sha1:f699988c411a588b278158bf6852b1a8c63c7454 Since there is currently only one error type that can occur when encoding, it doesn't make sense to use the full Error type here. This split will help us downstream, as we no longer need to categorize tor_bytes::Error as "an error in encoding or decoding". I considered renaming Error to DecodeError, but that had pretty huge downstream effects, and didn't seem to be worth it. 2022-06-22T14:02:42Z Nick Mathewson nickm@torproject.org 2022-06-22T14:02:42Z urn:sha1:c3da82fc2d44816a96ac6175a843321199f34af7 2022-06-22T13:00:59Z Nick Mathewson nickm@torproject.org 2022-06-22T13:00:59Z urn:sha1:3120f1092a1984a5904ad4772b9ead9e67905cec Also note an issue with the design of tor-bytes::Error that should probably go in a separate MR. 2022-06-10T11:30:22Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-06-10T11:30:22Z urn:sha1:03a19f3877c9ae5008f8a88caa978f8cd4aaf7d9 I disagree with almost all of these layout decisions... 2022-06-10T11:27:00Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-06-09T17:31:38Z urn:sha1:8fe63b3192ba631644fee561bb4ec895f2ae8d09 This eliminates the possibility of writing the bug of failing to call `should_be_exhausted`. As per this discussion https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/572#note_2811464 Fixes #498 2022-06-09T16:08:56Z Nick Mathewson nickm@torproject.org 2022-06-09T14:13:10Z urn:sha1:a2c6bd08fe90653dbe7b5889ef11ec9eec4c5c96