IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
480: build: fix wrong repo urls, clippies r=koivunej a=koivunej
I had forgotten some old urls there which are sure to cause build failures, as seen in the #479.
Co-authored-by: Joonas Koivunen <joonas.koivunen@gmail.com>
these query types were originally observing what kind of requests
conformance tests do and what kind of requests go-ipfs supports, so
keeping them as there might be some value. to be removed when upgrading
conformance tests.
this includes a change on making `unixfs::InvalidCidInLink` properly
`#[non_exhaustive]` instead of using the hidden field trick. it probably
isn't a breaking change, but then again requires a more recent rustc,
which sort of makes it a breaking change.
475: Fixing build issue described in: https://github.com/libp2p/rust-libp2p/issues/2231 r=koivunej a=karim-agha
When including rust-ipfs as a dependency in any crate, it fails with the following error:
```
error: failed to select a version for the requirement `aesni = "^0.7"`
candidate versions found which didn't match: 0.99.99, 0.10.0, 0.9.0, ...
location searched: crates.io index
required by package `aes v0.4.0`
... which is depended on by `aes-gcm v0.6.0`
... which is depended on by `snow v0.7.1`
... which is depended on by `libp2p-noise v0.30.0 (/home/alexander/dev/misc/rust-libp2p/transports/noise)`
... which is depended on by `libp2p v0.37.1 (/home/alexander/dev/misc/rust-libp2p)`
... which is depended on by `libp2p-relay v0.2.0 (/home/alexander/dev/misc/rust-libp2p/protocols/relay)`
```
This fix updates the libp2p version into one that has a fix for this dependency and now it compiles fine
Co-authored-by: Karim Agha <karim.dev@gmail.com>
When including rust-ipfs as a dependency in any crate, it fails with the following error:
```
error: failed to select a version for the requirement `aesni = "^0.7"`
candidate versions found which didn't match: 0.99.99, 0.10.0, 0.9.0, ...
location searched: crates.io index
required by package `aes v0.4.0`
... which is depended on by `aes-gcm v0.6.0`
... which is depended on by `snow v0.7.1`
... which is depended on by `libp2p-noise v0.30.0 (/home/alexander/dev/misc/rust-libp2p/transports/noise)`
... which is depended on by `libp2p v0.37.1 (/home/alexander/dev/misc/rust-libp2p)`
... which is depended on by `libp2p-relay v0.2.0 (/home/alexander/dev/misc/rust-libp2p/protocols/relay)`
```
This fix updates the libp2p version into one that has a fix for this dependency and now it compiles fine
473: Swarm cleanup following libp2p upgrade to v0.39.1 r=koivunej a=CHr15F0x
This is a follow up of https://github.com/rs-ipfs/rust-ipfs/pull/472. There are two changes introduced:
* remove eq_greedy as `Multiaddr` in `SwarmApi::pending_{addresses, connections}` contains p2p, align conversions accordingly (136496f7de),
* explicitly use `MultiaddrWithPeerId` in `SwarmApi::pending_{addresses, connections}` (3b6f69530f).
The former (136496f7de) works fine without the latter (3b6f69530f), however I am leaning more towards keeping both changes. Encoding the information about peer id presence/absence in Multiaddr in _type_ instead of relying on comments and `expect()`s improves readability and _developer experience_.
Please let me know what your thoughts are.
Co-authored-by: Krzysztof Lis <klis33@gmail.com>
Enforce internal represenatation for `SwarmApi::pending_{addresses, connections}` to explicitly show that all multiaddrs include peer IDs by using `MultiaddrWithPeerId`.
472: chore: upgrade to libp2p 0.39 r=koivunej a=CHr15F0x
This PR is a follow up of #463.
It includes the following:
- upgrading libp2p to [v.0.39.1](https://github.com/libp2p/rust-libp2p/releases/tag/v0.39.1)
- upgrading some other deps (e.g.: prost, prost-base, quick-protobuf, base64), **excluding cid and multihash**
- fixes to tests that started failing following upgrade to libp2p v.0.38 in #463
Incoming shortly:
- [x] respective changelog update
- [x] ~~I haven't run the changes against current workflow, so some additional fixes could be necessary;~~ edit: though I did check against all tests locally numerous times during dev, albeit only in a linux/x64 environment; btw looks like the workflows are fine with the changes
Co-authored-by: Joonas Koivunen <joonas.koivunen@gmail.com>
Co-authored-by: Krzysztof Lis <klis33@gmail.com>
Includes replacing `upgrade::{write_one, read_one}` with `upgrade::{write_length_prefixed, read_length_prefixed}` respectively, which is a direct consequence of [PR2111](https://github.com/libp2p/rust-libp2p/pull/2111).
471: ci: cache improvements r=koivunej a=Mirko-von-Leipzig
This PR improves the CI caching, roughly halving the time required when caches are hit (no dependency or toolchain changes).
Overview of changes:
- Use [rust-cache action](https://github.com/Swatinem/rust-cache). This forms the bulk of the time improvement as Rust dependencies are now cached.
- Improve npm caching for conformance tests. This trims 2-3 minutes of build time.
- Improve job and step naming.
- Add a manual trigger for the workflow.
- Remove core dump for macos, no longer required.
Further details can be found in the commits.
I've been running into sporadic conformance test failures on windows ([link to run](https://github.com/Mirko-von-Leipzig/rust-ipfs/actions/runs/1135372291)):
```
1) .pubsub.subscribe
multiple connected nodes
should send/receive 100 messages:
FetchError: request to http://127.0.0.1:50533/api/v0/pubsub/pub?arg=pubsub-tests-C-aIrZS_7OSQMNSVOMszV failed, reason: read ECONNRESET
at ClientRequest.<anonymous> (node_modules\node-fetch\lib\index.js:1455:11)
at Socket.socketErrorListener (_http_client.js:475:9)
at emitErrorNT (internal/streams/destroy.js:106:8)
at emitErrorCloseNT (internal/streams/destroy.js:74:3)
at processTicksAndRejections (internal/process/task_queues.js:82:21)
```
Co-authored-by: Mirko von Leipzig <mirko.vonleipzig@gmail.com>
467: Use hash_hasher in hashmaps/sets where the key is a Cid/Multihash #258 r=CHr15F0x a=CHr15F0x
This PR implements a fix for #258, ie. using hash_hasher to improve performance in HashMaps/Sets what utilize Cid as key. hash_hasher provides approx. 40% increase in performance in this case.
There are two things that still need to be done:
- code is **not linted** yet, since this will be done in a separate PR by Mirko,
- a simple benchmark is included for the sake of comparing HashedMap<Cid,> vs HashMap<Cid,>; Imho this bench should not be merged.
Co-authored-by: Krzysztof Lis <klis33@gmail.com>
470: fix: compilation error when used as a dependency r=koivunej a=koivunej
Fixes the issue reported in [comment of #458](https://github.com/rs-ipfs/rust-ipfs/issues/458#issuecomment-869208699) that whenever dependent on, even without any code calling `ipfs`, there is a build failure. This PR:
- removes top-level Cargo.lock now that I've learned why it's not good to keep around
- adds weekly scheduled build
- moves the `FsBlockStore::list` method body over to `FsBlockStore::list0` outside the `#[async_trait] impl BlockStore for FsBlockStore { ... }` where it does get the correct lifetimes inferred for the returned boxed future
The original compilation failure was caused by `async-trait` 0.1.42 => 0.1.43 upgrade deduced by bisecting Cargo.lock changes. It's still unknown why does the moved version work, but there are probably a lot of subleties to the code generated by `async-trait`. I don't yet know if this warrants any upstream bug reports; most likely not, we were stuck on a quite old version and many crates now work with it.
Co-authored-by: Joonas Koivunen <joonas.koivunen@gmail.com>
this was not set originally because probably mpart-async sets it, but
the code in `ipfs` assumed `std` feature was enabled and thus the from
conversion was accessible.
see comments in #458. it is unknown why this is needed but it does work
away of the compiler error.
it was later found out by bisecting Cargo.lock that this is caused by
async-trait 0.1.42 => 0.1.43 upgrade, but it's very unclear why this
would be caused by the only PR in that release.
466: In-memory reading from tar archives instead of extract to temp folder r=koivunej a=Scondo
Get rid of work with filesystem in fs-unrelated tests.
No more problems like https://github.com/rs-ipfs/rust-ipfs/issues/465 lead to tests failure.
Co-authored-by: Scondo <scondo@mail.ru>
