Commit Graph
26232 Commits
Author SHA1 Message Date
Paul Chobert ea92aa352c Send only state changes once the client has the announcement room
Any sync covering a room's first announcement delivers the room with full
state, so a client whose since token is past that announcement already has it.
2026-10-29 17:24:45 +01:00
Paul Chobert 7ac3351e25 Explain why announcement rooms are kept apart from joined rooms 2026-10-29 15:49:18 +01:00
Paul Chobert b898610f01 Cache get_server_announcement_room_ids 2026-10-29 10:58:46 +01:00
Paul Chobert 095333e31b Add first part of user_id and room_id to synthetic event ID 2026-10-29 10:47:20 +01:00
Paul Chobert d9ced20bbc Remove the is_announcement docstring 2026-10-28 10:55:15 +01:00
Paul Chobert 4f2bba6ba9 Simplify the synthetic join docstring 2026-10-28 10:52:00 +01:00
Paul Chobert 9e9d613663 Deliver announcement rooms for any new event after their first announcement 2026-10-28 10:42:19 +01:00
Paul Chobert 5700888e55 Explain why the synthetic join ignores the sync filter 2026-10-28 10:42:19 +01:00
Paul Chobert ed314d8022 Test device lists and state_after for announcement rooms 2026-10-28 10:42:19 +01:00
Paul Chobert da93cff424 Deliver announcement rooms whose last announcement is out of the timeline 2026-10-28 10:42:18 +01:00
Paul Chobert 96d8c3b66c Fix the announcement latency bound in the sync docstring 2026-10-28 10:42:18 +01:00
Paul Chobert eafdf9782b Explain why announcements do not wake up waiting syncs 2026-10-28 10:42:18 +01:00
Paul Chobert 4cff8e5eea Explain why announcement rooms have no unread counts 2026-10-28 10:42:18 +01:00
Paul Chobert acc6dd136c Explain why announcement rooms always carry full state 2026-10-28 10:42:18 +01:00
Paul Chobert 3b56c581f8 Spell out the no membership change case for announcement rooms 2026-10-28 10:42:18 +01:00
Paul Chobert 29eb4b5f44 Deliver announcement rooms in the sync that carries the user's leave 2026-10-28 10:42:18 +01:00
Paul Chobert 0b6a20fa1e Deliver announcements to members removed while offline on incremental sync 2026-10-28 10:42:17 +01:00
Paul Chobert f1d933c0e5 Deliver announcements to removed members on initial sync 2026-10-27 17:25:04 +01:00
Paul Chobert 14a30ca064 Strip the user's real membership from announcement room timelines 2026-10-27 17:20:41 +01:00
Paul Chobert 7f444b13b9 Add changelog entry 2026-10-27 14:23:55 +01:00
Paul Chobert ddf8b70388 Test server announcement delivery in legacy sync 2026-10-27 13:57:20 +01:00
Paul Chobert 647c846424 Deliver server announcements to non-members in legacy initial sync 2026-10-27 12:34:06 +01:00
Paul Chobert af50a3dde7 Deliver server announcements to non-members in legacy incremental sync 2026-10-27 12:34:06 +01:00
Eric Eastwood 4cece59c30 Drop support for Python 3.10 (#20359)
Fix https://github.com/element-hq/synapse/issues/20041

Keywords:

 - `3.10`
 - `py310`
 - `cp310`
2026-10-26 16:26:19 -05:00
Andrew MorganandPaul Chobert b27615282d [Server Announcements] [Create/Configure Rooms] Configure announcement rooms and reconcile them on startup (#20372)
Co-authored-by: Paul Chobert <paul@chobert.fr>
2026-10-26 17:20:04 +00:00
Johannes MarbachandOlivier 'reivilibre 0d28e93a7a Move the sticky events sliding sync extension to the global pos and MSC4508 scoping (#20363)
This includes the following:
    
- Implements ['Implicit Forward
Pagination'](https://github.com/matrix-org/matrix-spec/issues/2378).
Remove the extension's `since` and `next_batch` fields. The position is
now tracked via the global `pos`, with per-room connection state
recording how far each room has been sent so that `limit` paginates
without holding `pos` back and lost responses are re-delivered.
- Discussed in
https://github.com/matrix-org/matrix-spec-proposals/pull/4480#discussion_r4165887827
- Honour the `lists` and `rooms` fields.
- Send all unexpired sticky events when a room enters scope for the
first time or is newly joined, and catch up on events sent while a room
was out of scope when it re-enters.
- Enabling the extension partway through a connection returns all
unexpired sticky events for in-scope rooms, and re-enabling it after
disabling it returns the unexpired sticky events sent in the meantime.

I tried to split this up into standalone commits though the bulk of the
change is in the third commit.

---------

Co-authored-by: Olivier 'reivilibre <git.oo@emunest.net>
2026-10-26 14:02:22 +00:00
Hugh Nimmo-Smith d99e5fe783 Implement transaction IDs for MSC4388 and other updates (sign-in with QR code) (#19906) 2026-10-26 11:56:06 +00:00
Eric Eastwood 8d60450b33 Merge branch 'release-v1.164' into develop
Conflicts:
	CHANGES.md
	debian/changelog
2026-10-23 15:19:03 -05:00
Eric Eastwood aac366053f Merge branch 'master' into develop
Conflicts:
	pyproject.toml
2026-10-23 15:15:08 -05:00
Eric Eastwood 82c253f825 Clarify pillow bump only installable with Python >= 3.11 2026-10-23 15:01:53 -05:00
Eric Eastwood bcbf26641b Clarify pillow bump only installable with Python >= 3.11 2026-10-23 15:00:47 -05:00
Eric Eastwood 0a32d04b11 1.164.0rc3 v1.164.0rc3 2026-10-23 14:54:35 -05:00
Eric Eastwood 414abb9267 Bump pillow to version 13.0.0 with security fixes where Python support allows - Synapse 1.164.x (#20399)
The problem is that while `pillow@12.3.0` supports Python >= 3.10,
`pillow@13.0.0` only supports Python > 3.11, and we haven't dropped
support for Python 3.10 yet (tracked by
https://github.com/element-hq/synapse/issues/20041).

`pillow@13.0.0` includes some important security fixes:
https://pillow.readthedocs.io/en/stable/releasenotes/13.0.0.html

### How was this change made?

 1. `poetry update pillow`
1. Manually change the `"pillow"` `markers` in `poetry.lock` to split at
Python 3.11 instead of 3.14

Please note this is not a durable change. `poetry` will try to revert
this any time we try to make a change (requires diligence to make sure
we keep changing it back).

This maintenance burden will disappear once we drop Python 3.10 support
(tracked by https://github.com/element-hq/synapse/issues/20041).

### Alternatives

If we were up for updating the minimum version of `pillow` in
`pyproject.toml`, we could do something like the following which would
resolve in `poetry.lock` durably how we want,

`pyproject.toml`
```
    # Pillow 13 dropped Python 3.10 but has security fixes. Split so 3.11+ can pick up
    # the security fixes.
    #
    # FIXME: Remove the split once we drop Python 3.10 support.
    "Pillow>=10.0.1,<13; python_version < '3.11'",
    "Pillow>=13.0.0; python_version >= '3.11'",
```

It looks like we [previously
bumped](https://github.com/element-hq/synapse/blob/4853cd4238e100183fd7b0852ddf3e8eef894658/pyproject.toml#L54-L56)
the minimum version of `Pillow` for another CVE
(https://github.com/matrix-org/synapse/pull/16347)

Although, I'm guessing we'd rather leave the minimum version alone and
only update `poetry.lock`.

I think the problem with updating the minimum is that the packagers for
Linux distros will have to deal with not having the latest `pillow`
version available and may patch `pillow` a different way.
2026-10-23 14:52:14 -05:00
Eric Eastwood 62a411da7e 1.163.2 v1.163.2 2026-10-23 14:50:01 -05:00
Eric Eastwood f8a70f5424 Bump pillow to version 13.0.0 with security fixes where Python support allows (#20398)
The problem is that while `pillow@12.3.0` supports Python >= 3.10,
`pillow@13.0.0` only supports Python > 3.11, and we haven't dropped
support for Python 3.10 yet (tracked by
https://github.com/element-hq/synapse/issues/20041).

`pillow@13.0.0` includes some important security fixes:
https://pillow.readthedocs.io/en/stable/releasenotes/13.0.0.html

### How was this change made?

 1. `poetry update pillow`
1. Manually change the `"pillow"` `markers` in `poetry.lock` to split at
Python 3.11 instead of 3.14

Please note this is not a durable change. `poetry` will try to revert
this any time we try to make a change (requires diligence to make sure
we keep changing it back).

This maintenance burden will disappear once we drop Python 3.10 support
(tracked by https://github.com/element-hq/synapse/issues/20041).

### Alternatives

If we were up for updating the minimum version of `pillow` in
`pyproject.toml`, we could do something like the following which would
resolve in `poetry.lock` durably how we want,

`pyproject.toml`
```
    # Pillow 13 dropped Python 3.10 but has security fixes. Split so 3.11+ can pick up
    # the security fixes.
    #
    # FIXME: Remove the split once we drop Python 3.10 support.
    "Pillow>=10.0.1,<13; python_version < '3.11'",
    "Pillow>=13.0.0; python_version >= '3.11'",
```

It looks like we [previously
bumped](https://github.com/element-hq/synapse/blob/4853cd4238e100183fd7b0852ddf3e8eef894658/pyproject.toml#L54-L56)
the minimum version of `Pillow` for another CVE
(https://github.com/matrix-org/synapse/pull/16347)

Although, I'm guessing we'd rather leave the minimum version alone and
only update `poetry.lock`.

I think the problem with updating the minimum is that the packagers for
Linux distros will have to deal with not having the latest `pillow`
version available and may patch `pillow` a different way.
2026-10-23 14:48:11 -05:00
Junker der Provinz 4853cd4238 Remove $server_port from the Host header in the nginx reverse proxy example (#20391)
Fixes #19583

The nginx example in `docs/reverse_proxy.md` sets `proxy_set_header Host
$host:$server_port;`. The server block listens on 443, so nginx sends
`Host: matrix.example.com:443`. With `public_baseurl:
https://matrix.example.com/`, the request URI never starts with
`public_baseurl`, and `SsoRedirectServlet` keeps redirecting to itself.
That breaks SSO even when the internal and external ports are the same.
The line came in with #17994.

This switches the example to `proxy_set_header Host $host;`, as
@anoadragon453 recommended in #18359. I added a short comment for setups
where clients use a non-default port: use `$http_host` and put that port
in `public_baseurl`. The setup in #18359 (external port 50080) needs
that variant.

I left `docker/conf-workers/nginx.conf.j2` alone. Its listener port
matches `public_baseurl`, so `$host:$server_port` is right there.

This is a docs-only change, so there are no tests.

Thanks to @shibotto for reporting this and for pointing at the fix.

### Pull Request Checklist

<!-- Please read
https://element-hq.github.io/synapse/latest/development/contributing_guide.html
before submitting your pull request -->

* [x] Pull request is based on the develop branch
* [x] Pull request includes a [changelog
file](https://element-hq.github.io/synapse/latest/development/contributing_guide.html#changelog).
The entry should:
- Be a short description of your change which makes sense to users.
"Fixed a bug that prevented receiving messages from other servers."
instead of "Moved X method from `EventStore` to `EventWorkerStore`.".
  - Use markdown where necessary, mostly for `code blocks`.
  - End with either a period (.) or an exclamation mark (!).
  - Start with a capital letter.
- Feel free to credit yourself, by adding a sentence "Contributed by
@github_username." or "Contributed by [Your Name]." to the end of the
entry.
* [x] [Code
style](https://element-hq.github.io/synapse/latest/code_style.html) is
correct (run the
[linters](https://element-hq.github.io/synapse/latest/development/contributing_guide.html#run-the-linters))
2026-10-23 17:19:34 +00:00
Eric Eastwood 7ea942a5fe Merge branch 'release-v1.164' into develop
Conflicts:
	CHANGES.md
	debian/changelog
2026-10-22 14:51:16 -05:00
Eric Eastwood 06a1c55e56 1.164.0rc2 v1.164.0rc2 2026-10-22 14:32:23 -05:00
Eric Eastwood 2d7cccc87a Merge branch 'release-v1.164' of github.com:element-hq/synapse into release-v1.164 2026-10-22 14:30:33 -05:00
Eric Eastwood 603fb5bb39 Merge branch 'master' into develop
Conflicts:
	CHANGES.md
	debian/changelog
	pyproject.toml
2026-10-22 14:28:08 -05:00
Eric Eastwood b4daaca31f Update rustls-webpki to distrust eMudhra Intermediate certificates (#20392)
`rustls-webpki` releasenotes: https://github.com/rustls/webpki/releases/tag/v%2F0.103.16

Part of https://github.com/element-hq/backend-internal/issues/306

Related to https://github.com/element-hq/synapse/pull/20387

We already use the system CA store when making requests in our Rust code
(using the
[`rustls-tls-native-roots`](https://github.com/element-hq/synapse/blob/7c85c80033ea5c3ca3851f3dab1d0397b94d5183/rust/Cargo.toml#L61)
([docs](https://docs.rs/reqwest/0.12.28/reqwest/#optional-features))
feature with `reqwest`). For a system that already has a patched system
CA store, bumping `rustls-webpki` is simply extra protection as it
actively blocks those untrusted certs. For an unpatched system CA store,
this provides a stop-gap.


### Dev notes

```shell
$ cargo tree --invert rustls-webpki
rustls-webpki v0.103.16
└── rustls v0.23.45
    ├── hyper-rustls v0.27.7
    │   └── reqwest v0.12.28
    │       └── synapse v0.1.0 (/home/eric/Documents/github/element/synapse/rust)
    ├── reqwest v0.12.28 (*)
    └── tokio-rustls v0.26.2
        ├── hyper-rustls v0.27.7 (*)
        └── reqwest v0.12.28 (*)
```
2026-10-22 14:13:24 -05:00
Bardi Harborow c4680b6b81 security: update certifi to 2026.10.19 (#20387)
Updates `certifi` to 2026.10.19 to address
[GHSA-6q48-6c7w-9gw2](https://github.com/advisories/GHSA-6q48-6c7w-9gw2).

certifi before 2026.10.19 bundles `emSign ECC Root CA - G3`, which
chains to the compromised eMudhra intermediate CAs.

This only affects TLS connections made by the Sentry SDK when `sentry`
is configured, as `sentry_sdk`'s transport is the only runtime user of
certifi. Federation and Synapse's other outbound HTTP requests use the
system trust store via `platformTrust()`.

Python advisory:
https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576

---------

Signed-off-by: Bardi Harborow <bardi@bardiharborow.com>
2026-10-22 14:13:24 -05:00
Eric Eastwood 56913c3d71 1.163.1 v1.163.1 2026-10-22 14:01:36 -05:00
Eric Eastwood 3f2bef9429 Update rustls-webpki to distrust eMudhra Intermediate certificates (#20392)
`rustls-webpki` releasenotes: https://github.com/rustls/webpki/releases/tag/v%2F0.103.16

Part of https://github.com/element-hq/backend-internal/issues/306

Related to https://github.com/element-hq/synapse/pull/20387

We already use the system CA store when making requests in our Rust code
(using the
[`rustls-tls-native-roots`](https://github.com/element-hq/synapse/blob/7c85c80033ea5c3ca3851f3dab1d0397b94d5183/rust/Cargo.toml#L61)
([docs](https://docs.rs/reqwest/0.12.28/reqwest/#optional-features))
feature with `reqwest`). For a system that already has a patched system
CA store, bumping `rustls-webpki` is simply extra protection as it
actively blocks those untrusted certs. For an unpatched system CA store,
this provides a stop-gap.


### Dev notes

```shell
$ cargo tree --invert rustls-webpki
rustls-webpki v0.103.16
└── rustls v0.23.45
    ├── hyper-rustls v0.27.7
    │   └── reqwest v0.12.28
    │       └── synapse v0.1.0 (/home/eric/Documents/github/element/synapse/rust)
    ├── reqwest v0.12.28 (*)
    └── tokio-rustls v0.26.2
        ├── hyper-rustls v0.27.7 (*)
        └── reqwest v0.12.28 (*)
```
2026-10-22 13:50:51 -05:00
Bardi Harborow c3adef6578 security: update certifi to 2026.10.19 (#20387)
Updates `certifi` to 2026.10.19 to address
[GHSA-6q48-6c7w-9gw2](https://github.com/advisories/GHSA-6q48-6c7w-9gw2).

certifi before 2026.10.19 bundles `emSign ECC Root CA - G3`, which
chains to the compromised eMudhra intermediate CAs.

This only affects TLS connections made by the Sentry SDK when `sentry`
is configured, as `sentry_sdk`'s transport is the only runtime user of
certifi. Federation and Synapse's other outbound HTTP requests use the
system trust store via `platformTrust()`.

Python advisory:
https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576

---------

Signed-off-by: Bardi Harborow <bardi@bardiharborow.com>
2026-10-22 13:50:51 -05:00
Eric Eastwood 3366ea72cf Update rustls-webpki to distrust eMudhra Intermediate certificates (#20392)
`rustls-webpki` releasenotes: https://github.com/rustls/webpki/releases/tag/v%2F0.103.16

Part of https://github.com/element-hq/backend-internal/issues/306

Related to https://github.com/element-hq/synapse/pull/20387

We already use the system CA store when making requests in our Rust code
(using the
[`rustls-tls-native-roots`](https://github.com/element-hq/synapse/blob/7c85c80033ea5c3ca3851f3dab1d0397b94d5183/rust/Cargo.toml#L61)
([docs](https://docs.rs/reqwest/0.12.28/reqwest/#optional-features))
feature with `reqwest`). For a system that already has a patched system
CA store, bumping `rustls-webpki` is simply extra protection as it
actively blocks those untrusted certs. For an unpatched system CA store,
this provides a stop-gap.


### Dev notes

```shell
$ cargo tree --invert rustls-webpki
rustls-webpki v0.103.16
└── rustls v0.23.45
    ├── hyper-rustls v0.27.7
    │   └── reqwest v0.12.28
    │       └── synapse v0.1.0 (/home/eric/Documents/github/element/synapse/rust)
    ├── reqwest v0.12.28 (*)
    └── tokio-rustls v0.26.2
        ├── hyper-rustls v0.27.7 (*)
        └── reqwest v0.12.28 (*)
```
2026-10-22 09:49:50 -05:00
Johannes Marbach c54fd437e3 Switch the RTC notification rules to event-property-is (#20366)
As suggested in
https://github.com/matrix-org/matrix-spec-proposals/pull/4075#discussion_r4288130493.
2026-10-22 13:13:46 +01:00
Bardi Harborow 87b082f23a security: update certifi to 2026.10.19 (#20387)
Updates `certifi` to 2026.10.19 to address
[GHSA-6q48-6c7w-9gw2](https://github.com/advisories/GHSA-6q48-6c7w-9gw2).

certifi before 2026.10.19 bundles `emSign ECC Root CA - G3`, which
chains to the compromised eMudhra intermediate CAs.

This only affects TLS connections made by the Sentry SDK when `sentry`
is configured, as `sentry_sdk`'s transport is the only runtime user of
certifi. Federation and Synapse's other outbound HTTP requests use the
system trust store via `platformTrust()`.

Python advisory:
https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576

---------

Signed-off-by: Bardi Harborow <bardi@bardiharborow.com>
2026-10-21 19:29:23 -05:00
Olivier 'reivilibre 7c85c80033 Unbreak CI by bumping locked dependencies to support Python 3.15 wheels. (#20386)
It looks like our CI is sometimes being run with Python 3.15, where
`rpds-py` doesn't have wheels for our current version.

Unsure why it's intermittent.

Run:
https://github.com/element-hq/synapse/actions/runs/39464528041/job/118772376619

```
      | error: failed to run custom build command for `pyo3-ffi v0.27.2`
      | 
      | Caused by:
      |   process didn't exit successfully: `/tmp/tmp72_cy3_y/rpds_py-0.30.0/target/release/build/pyo3-ffi-ae84d9db989de8cd/build-script-build` (exit status: 1)
      |   --- stdout
      |   cargo:rustc-check-cfg=cfg(Py_LIMITED_API)
      |   cargo:rustc-check-cfg=cfg(Py_GIL_DISABLED)
      |   cargo:rustc-check-cfg=cfg(PyPy)
      |   cargo:rustc-check-cfg=cfg(GraalPy)
      |   cargo:rustc-check-cfg=cfg(py_sys_config, values("Py_DEBUG", "Py_REF_DEBUG", "Py_TRACE_REFS", "COUNT_ALLOCS"))
      |   cargo:rustc-check-cfg=cfg(pyo3_disable_reference_pool)
      |   cargo:rustc-check-cfg=cfg(pyo3_leak_on_drop_without_reference_pool)
      |   cargo:rustc-check-cfg=cfg(Py_3_7)
      |   cargo:rustc-check-cfg=cfg(Py_3_8)
      |   cargo:rustc-check-cfg=cfg(Py_3_9)
      |   cargo:rustc-check-cfg=cfg(Py_3_10)
      |   cargo:rustc-check-cfg=cfg(Py_3_11)
      |   cargo:rustc-check-cfg=cfg(Py_3_12)
      |   cargo:rustc-check-cfg=cfg(Py_3_13)
      |   cargo:rustc-check-cfg=cfg(Py_3_14)
      |   cargo:rustc-check-cfg=cfg(Py_3_15)
      |   cargo:rerun-if-env-changed=PYO3_CROSS
      |   cargo:rerun-if-env-changed=PYO3_CROSS_LIB_DIR
      |   cargo:rerun-if-env-changed=PYO3_CROSS_PYTHON_VERSION
      |   cargo:rerun-if-env-changed=PYO3_CROSS_PYTHON_IMPLEMENTATION
      |   cargo:rerun-if-env-changed=PYO3_PRINT_CONFIG
      |   cargo:rerun-if-env-changed=PYO3_USE_ABI3_FORWARD_COMPATIBILITY
      | 
      |   --- stderr
      |   error: the configured Python version (3.15) is newer than PyO3's maximum supported version (3.14)
      |   = help: this package is being built with PyO3 version 0.27.2
      |   = help: check https://crates.io/crates/pyo3 for the latest PyO3 version available
      |   = help: updating this package to the latest version of PyO3 may provide compatibility with this Python version
      |   = help: set PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 to suppress this check and build anyway using the stable ABI
      | warning: build failed, waiting for other jobs to finish...
      | 💥 maturin failed
      |   Caused by: Failed to build a native library through cargo
      |   Caused by: Cargo build finished with "exit status: 101": `env -u CARGO PYO3_BUILD_EXTENSION_MODULE="1" PYO3_ENVIRONMENT_SIGNATURE="cpython-3.15-64bit" PYO3_PYTHON="/tmp/tmpy90bal2g/.venv/bin/python" PYTHON_SYS_EXECUTABLE="/tmp/tmpy90bal2g/.venv/bin/python" "cargo" "rustc" "--profile" "release" "--features" "pyo3/extension-module" "--message-format" "json-render-diagnostics" "--manifest-path" "/tmp/tmp72_cy3_y/rpds_py-0.30.0/Cargo.toml" "--lib"`
      | Error: command ['maturin', 'pep517', 'build-wheel', '-i', '/tmp/tmpy90bal2g/.venv/bin/python', '--compatibility', 'off'] returned non-zero exit status 1
  
  Note: This error originates from the build backend, and is likely not a problem with poetry but one of the following issues with rpds-py (0.30.0)
  
    - not supporting PEP 517 builds
    - not specifying PEP 517 build requirements correctly
    - the build requirements are incompatible with your operating system or Python version
    - the build requirements are missing system dependencies (eg: compilers, libraries, headers).
  
  You can verify this by running pip wheel --no-cache-dir --use-pep517 "rpds-py (==0.30.0)".
  
  
  PEP517 build of a dependency failed
```


```
      | error: failed to run custom build command for `pyo3-ffi v0.26.0`
      | 
      | Caused by:
      |   process didn't exit successfully: `/tmp/tmpy_lu888j/pydantic_core-2.41.5/target/release/build/pyo3-ffi-83252c0f9cb4430a/build-script-build` (exit status: 1)
      |   --- stdout
      |   cargo:rustc-check-cfg=cfg(Py_LIMITED_API)
      |   cargo:rustc-check-cfg=cfg(Py_GIL_DISABLED)
      |   cargo:rustc-check-cfg=cfg(PyPy)
      |   cargo:rustc-check-cfg=cfg(GraalPy)
      |   cargo:rustc-check-cfg=cfg(py_sys_config, values("Py_DEBUG", "Py_REF_DEBUG", "Py_TRACE_REFS", "COUNT_ALLOCS"))
      |   cargo:rustc-check-cfg=cfg(pyo3_disable_reference_pool)
      |   cargo:rustc-check-cfg=cfg(pyo3_leak_on_drop_without_reference_pool)
      |   cargo:rustc-check-cfg=cfg(Py_3_7)
      |   cargo:rustc-check-cfg=cfg(Py_3_8)
      |   cargo:rustc-check-cfg=cfg(Py_3_9)
      |   cargo:rustc-check-cfg=cfg(Py_3_10)
      |   cargo:rustc-check-cfg=cfg(Py_3_11)
      |   cargo:rustc-check-cfg=cfg(Py_3_12)
      |   cargo:rustc-check-cfg=cfg(Py_3_13)
      |   cargo:rustc-check-cfg=cfg(Py_3_14)
      |   cargo:rustc-check-cfg=cfg(Py_3_15)
      |   cargo:rerun-if-env-changed=PYO3_CROSS
      |   cargo:rerun-if-env-changed=PYO3_CROSS_LIB_DIR
      |   cargo:rerun-if-env-changed=PYO3_CROSS_PYTHON_VERSION
      |   cargo:rerun-if-env-changed=PYO3_CROSS_PYTHON_IMPLEMENTATION
      |   cargo:rerun-if-env-changed=PYO3_PRINT_CONFIG
      |   cargo:rerun-if-env-changed=PYO3_USE_ABI3_FORWARD_COMPATIBILITY
      | 
      |   --- stderr
      |   error: the configured Python interpreter version (3.15) is newer than PyO3's maximum supported version (3.14)
      |   = help: please check if an updated version of PyO3 is available. Current version: 0.26.0
      |   = help: set PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 to suppress this check and build anyway using the stable ABI
      | warning: build failed, waiting for other jobs to finish...
      | 💥 maturin failed
      |   Caused by: Failed to build a native library through cargo
      |   Caused by: Cargo build finished with "exit status: 101": `env -u CARGO PYO3_BUILD_EXTENSION_MODULE="1" PYO3_ENVIRONMENT_SIGNATURE="cpython-3.15-64bit" PYO3_PYTHON="/tmp/tmprci5om5_/.venv/bin/python" PYTHON_SYS_EXECUTABLE="/tmp/tmprci5om5_/.venv/bin/python" "cargo" "rustc" "--profile" "release" "--message-format" "json-render-diagnostics" "--manifest-path" "/tmp/tmpy_lu888j/pydantic_core-2.41.5/Cargo.toml" "--lib" "--crate-type" "cdylib"`
      | Error: command ['maturin', 'pep517', 'build-wheel', '-i', '/tmp/tmprci5om5_/.venv/bin/python', '--compatibility', 'off'] returned non-zero exit status 1
  
  Note: This error originates from the build backend, and is likely not a problem with poetry but one of the following issues with pydantic-core (2.41.5)
  
    - not supporting PEP 517 builds
    - not specifying PEP 517 build requirements correctly
    - the build requirements are incompatible with your operating system or Python version
    - the build requirements are missing system dependencies (eg: compilers, libraries, headers).
  
  You can verify this by running pip wheel --no-cache-dir --use-pep517 "pydantic-core (==2.41.5)".
```

---------

Signed-off-by: Olivier 'reivilibre <oliverw@matrix.org>
2026-10-21 10:51:49 -05:00
Eric Eastwood 80d50913d6 Organize MSC4354 bugfixes with the others v1.164.0rc1 2026-10-20 09:54:17 -05:00