mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.3.0 2022-05-06T14:03:15Z 2022-05-06T14:03:15Z Nick Mathewson nickm@torproject.org 2022-05-06T14:03:15Z urn:sha1:7b93091f57f43ec8543a17052d60a2c8f7f2b0cc * Except for safelog and fs-mistrust, which are new. 2022-05-06T12:36:40Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-05-06T12:18:03Z urn:sha1:030289481f79d7b1de4084e485b1793042b36ee8 For reference, the git source for this crate (and the others in its workspace) currently lives in my personal github account (ijackson). If this fork turns out to be long-lived and gains features and/or users, it would be good to move it to a gitlab somewhere. I have granted Nick crate ownership on the crates.io system. 2022-04-27T14:31:08Z eta tor@eta.st 2022-04-27T14:31:08Z urn:sha1:6f787e1e7707c2125a5d0df457e7894f944f4aa6 derive_builder: Use git dep everywhere, rather than cargo patch See merge request tpo/core/arti!477 2022-04-27T13:57:59Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-04-27T13:44:59Z urn:sha1:a97ad69855cdf1931e29cc024a79336448f50990 The `[patch]` approach causes the tree not to build when used as a dependency, unless the `[patch]` is replicated into the depending project. Instead, replace our `derive_builer =` dependencies with a reference to a specific git commit: perl -i~ -pe 'next unless m/^derive_builder/; s#"(0\.11\.2)"#{ version = "$1", git = "https://github.com/ijackson/rust-derive-builder", rev = "ba0c1a5311bd9f93ddf5f5b8ec2a5f6f03b22fbe" }#' crates/*/Cargo.toml Note that the commitid has changed. This is because derive_builder is in fact a workspace of 4 crates. 3 of them are of interest to arti itself (the 4th exists only for testing). So the same "add git revision" treatment had to be done to the `derive_builder` and `derive_builder_macro` crates. Each dependency edge involves a new commit in the derive_builder workspace, since we can't create a git commit containing its own commitid. (We want to use commits, rather than a branch, so that what we are depending on is actually properly defined, and not subject to the whims of my personal github namespace.) There are no actual code changes in derive_builder. 2022-04-26T16:16:22Z Nick Mathewson nickm@torproject.org 2022-04-25T20:13:21Z urn:sha1:6b5cefcccf132725bd6be54d938cfa66ed8e1dc6 2022-04-25T17:05:31Z Nick Mathewson nickm@torproject.org 2022-04-25T16:19:02Z urn:sha1:b60b0a266a145d36950df638c83f8c4d55b6ae0b This is an automated change made with a perl one-liner and verified with grep -L and grep -l. Some warnings are introduced with this change; they will be removed in subsequent commits. See arti#208 for older discussion on this issue. 2022-04-25T17:04:31Z Nick Mathewson nickm@torproject.org 2022-04-25T16:10:41Z urn:sha1:ca05b0904c2fbb0c866127a78728cab7be28d61f This change was made automatically with a perl one-liner, and confirmed with `grep -L`. The `rust-version` field itself was introduced in 1.56.0. 2022-04-25T17:04:31Z Nick Mathewson nickm@torproject.org 2022-04-25T16:03:41Z urn:sha1:0069fd2206b2cbc612474e7d70fda0af9cfcae2d There are no semantic changes here; only formatting. This is in preparation for other changes (wrt MSRV and edition) 2022-04-21T13:07:28Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-04-21T11:03:36Z urn:sha1:6da7a2e3e2c33b4a1448632a41e11210690c6f52 This commitid is the current head of my MR branch https://github.com/colin-kiegel/rust-derive-builder/pull/253 https://github.com/ijackson/rust-derive-builder/tree/field-builder Using the commitid prevents surprises if that branch is updated. We will require this newer version of derive_builder. The version will need to be bumped again later, assuming the upstream MR is merged and upstream do a release containing the needed changes. We will need the new version of not only `derive_builder_core` (the main macro implementation) but also`derive_builder` for a new error type. 2022-04-01T13:15:18Z Nick Mathewson nickm@torproject.org 2022-04-01T13:15:18Z urn:sha1:5b2fc118df0524144e6b2c34fdcce3d0fb692d24 Not all of these strictly need to be bumped to 0.2.0; many could go to 0.1.1 instead. But since everything at the tor-rtcompat and higher layers has had breaking API changes, it seems not so useful to distinguish. (It seems unlikely that anybody at this stage is depending on e.g. tor-protover but not arti-client.)