Skip to content

Conversation

divagant-martian
Copy link

@divagant-martian divagant-martian commented Sep 29, 2025

we were behind around 170 commits, many many had conflicts. Every commit that had a conflict has an individual merge commit. I would prefer to keep the individual merges for future conflicts. This is because future conflicts will go against the individual merges instead of a messy 170 commit merge that gives truly no info on how the conflict was solved

djc and others added 30 commits January 30, 2025 20:28
This is newly required for libfuzzer-sys 0.4.9. It is a permissive
license similar to the MIT or 3-claused BSD licenses.
On MacOS < 14, with `fast-apple-datapath` feature, calls to
`libc::CMSG_NXTHDR` might continuously return empty (i.e. all zero)
`libc::cmsghdr` instead of a null pointer. This results in a busy loop
in `decode_recv`:

``` rust
let cmsg_iter = unsafe { cmsg::Iter::new(hdr) };
for cmsg in cmsg_iter {
	match (cmsg.cmsg_level, cmsg.cmsg_type) {
```
https://github.com/quinn-rs/quinn/blob/b4378bb39dab4b58a1e6a3fea4fff9f87033dab6/quinn-udp/src/unix.rs#L685C1-L687C50

This commit fixes the above, returning a `null_mut()` pointer on an
empty `libc::cmsgdhr`, thus terminating the `cmsg_iter`.

See also mozilla/neqo#2427 for details.
This was the only case where `Instant::now()` is used in quinn-proto or quinn-udp for anything other than tests or rate-limiting logging. Making this change to keep these two crates more IO-agnostic.
We depend on new APIs, e.g. for token logs.
This caused rare flakes in at least
single_ack_eliciting_packet_triggers_ack_after_delay by classifying a
the connection as active for longer than expected.
This reverts the change that tries to avoid sending a PING frame if
there are user datagrams to send.  The problem is that the user
dataram might not fit in the probe that will be sent.

It is possible to do this better, but the quick thing is to accept the
extra ping frame, the space wasted because of this is rather minimal.
And if a user was sending user datagrams at just the right MTU size it
is unlikely they would fit in the next packet anyway since typically
the probe packet will end up with a smaller size-limit compared to the
MTU.
When needing to send tail-loss probes and building a GSO batch the
tail-loss probe should not exceed the GSO segment size.
Also includes getters for the current sizes and a test.
Bump version to 0.5.11.
…tu is large enough to batch

When a TLP is the first in the batch and initial mtu is large enough to allow for batching it still should
stay under the max_datagrams limit
separate certificate's examples out of md file into rs files

format
stormshield-damiend and others added 21 commits August 20, 2025 10:51
Bumps [url](https://github.com/servo/rust-url) from 2.5.4 to 2.5.7.
- [Release notes](https://github.com/servo/rust-url/releases)
- [Commits](https://github.com/servo/rust-url/commits)

---
updated-dependencies:
- dependency-name: url
  dependency-version: 2.5.7
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <[email protected]>
Bumps [actions/setup-java](https://github.com/actions/setup-java) from 4 to 5.
- [Release notes](https://github.com/actions/setup-java/releases)
- [Commits](actions/setup-java@v4...v5)

---
updated-dependencies:
- dependency-name: actions/setup-java
  dependency-version: '5'
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <[email protected]>
Bumps [serde_json](https://github.com/serde-rs/json) from 1.0.142 to 1.0.143.
- [Release notes](https://github.com/serde-rs/json/releases)
- [Commits](serde-rs/json@v1.0.142...v1.0.143)

---
updated-dependencies:
- dependency-name: serde_json
  dependency-version: 1.0.143
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <[email protected]>
@n0bot n0bot bot added this to iroh Sep 29, 2025
@github-project-automation github-project-automation bot moved this to 🏗 In progress in iroh Sep 29, 2025
@flub
Copy link
Collaborator

flub commented Sep 29, 2025

I'm surprised this is merging into iroh-0.11.x rather than multipath-quinn-0.11.x. The latter is only 73 commits behind quinn-rs/quinn:main. We've previously merged quinn-rs/quinn:main directly into multipath-quinn-0.11.x without using iroh-0.11.x.

I was expecting that multipath-quinn-0.11.x would become the branch we next release from, leaving iroh-0.11.x behind. The changes in iroh-0.11.x that are not in multipath-quinn-0.11.x are either already there differently or not very relevant I think: multipath-quinn-0.11.x...n0-computer:quinn:iroh-0.11.x

@divagant-martian
Copy link
Author

when I asked about a reminder to our merge process this is the main branch I meant.

I'm going to merge this then and we can decide what our next release will be, while the multipath merge is finished

@divagant-martian divagant-martian force-pushed the iroh-0.11.x-b2b930a-merges branch from 92658ac to 070b6db Compare September 29, 2025 13:55
@divagant-martian divagant-martian merged commit e4f99fd into iroh-0.11.x Sep 29, 2025
@divagant-martian divagant-martian deleted the iroh-0.11.x-b2b930a-merges branch September 29, 2025 13:56
@github-project-automation github-project-automation bot moved this from 🏗 In progress to ✅ Done in iroh Sep 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.