This is only really needed for Track, a custom field that has a
manually-maintained mapping to the area labels on PRs, but it's a cheap
enough operation for the rest of them. Follow-up to
https://github.com/zed-industries/zed/pull/64650
Release Notes:
- N/A
This PR contains the following updates:
| Package | Change |
[Age](https://docs.renovatebot.com/merge-confidence/) |
[Confidence](https://docs.renovatebot.com/merge-confidence/) |
|---|---|---|---|
| [urllib3](https://redirect.github.com/urllib3/urllib3)
([changelog](https://redirect.github.com/urllib3/urllib3/blob/main/CHANGES.rst))
| `2.7.0` → `2.8.0` |
|
|
---
> [!WARNING]
> Some dependencies could not be looked up. Check the [Dependency
Dashboard](../issues/15138) for more information.
---
### urllib3: HTTPS proxy TLS configuration may be ignored or overridden
[CVE-2026-97687](https://nvd.nist.gov/vuln/detail/CVE-2026-97687) /
[GHSA-8988-9cw3-xx77](https://redirect.github.com/advisories/GHSA-8988-9cw3-xx77)
<details>
<summary>More information</summary>
#### Details
##### Impact
urllib3 supports configuring TLS independently for an HTTPS proxy and
the target server.
`proxy_ssl_context`, `proxy_assert_hostname`, and
`proxy_assert_fingerprint` configure the TLS connection to the proxy.
`ssl_context` and the other target-specific TLS parameters configure the
connection to the target server.
In urllib3 versions 1.26.0 through 2.7.0, these configurations were not
consistently separated. Depending on the proxy mode, urllib3 could:
1. Ignore `proxy_ssl_context` and use the target server's SSL context
for the TLS connection to an HTTPS forwarding proxy.
2. Override the HTTPS proxy's certificate-verification policy with the
target server's certificate-verification policy.
3. Apply target-specific SNI, hostname assertions, certificate
fingerprint assertions, or TLS client credentials to the TLS connection
to an HTTPS forwarding proxy.
In particular, configuring `cert_reqs="CERT_NONE"` for a target server
could overwrite the `verify_mode` of the SSL context configured for the
HTTPS proxy. This modification occurred in place and persisted on the
context object, potentially disabling proxy certificate verification for
later connections that reused the same context.
An attacker able to intercept the connection to an HTTPS proxy may be
able to impersonate the proxy when the effective proxy TLS configuration
disables certificate verification or otherwise accepts the attacker's
certificate. This may occur, for example, when the target server's trust
or identity policy is incorrectly applied to the proxy connection.
When HTTPS forwarding is enabled, an impersonated proxy can observe or
modify forwarded requests and responses, potentially exposing
credentials, authentication tokens, request bodies, response data, and
other sensitive information.
A TLS client certificate intended for the target server may also be
presented to the proxy or to an attacker impersonating it. This can
disclose the client's identity and provide proof of possession of the
corresponding private key. The private key itself is not transmitted
during the TLS handshake.
In CONNECT tunneling mode, impersonating the HTTPS proxy does not by
itself defeat the separate end-to-end TLS connection between the client
and the target server.
##### Affected Usages
Code using urllib3 versions 1.26.0 through 2.7.0 may be affected in any
of the following cases.
##### 1. The target SSL context is used for an HTTPS forwarding proxy
HTTPS requests are forwarded through an HTTPS proxy with
`use_forwarding_for_https=True`, and `proxy_ssl_context` is configured
for the proxy.
urllib3 may ignore `proxy_ssl_context` and use the target server's
`ssl_context` for the proxy TLS handshake. The proxy may therefore be
verified using the target server's trust and certificate policy instead
of the policy explicitly configured for the proxy.
##### 2. The target verification policy overrides the proxy policy
An HTTPS proxy is configured with `proxy_ssl_context`, while the target
server uses a different certificate-verification policy.
urllib3 may apply the target server's `cert_reqs` value to the proxy SSL
context. For example, setting `cert_reqs="CERT_NONE"` for the target
server may also disable certificate verification for the HTTPS proxy,
even when `proxy_ssl_context` was configured to require verification.
This issue can affect the TLS connection to an HTTPS proxy in both
forwarding and CONNECT tunneling configurations.
##### 3. A mutated proxy SSL context is reused
The same SSL context is reused as `proxy_ssl_context` across multiple
connections, and certificate verification is disabled for one target
server.
urllib3 may modify the proxy SSL context's `verify_mode` in place. Later
connections that reuse the same context may therefore connect to the
HTTPS proxy without certificate verification.
##### 4. Target-specific TLS identity or credentials are applied to the
proxy
HTTPS requests are forwarded through an HTTPS proxy with
`use_forwarding_for_https=True`, and target-specific SNI, hostname
assertions, certificate fingerprint assertions, or TLS client
credentials are configured.
urllib3 may apply these target-specific settings to the proxy TLS
handshake. This may cause urllib3 to:
- send SNI intended for the target server to the proxy;
- verify the proxy using a hostname or certificate fingerprint intended
for the target server; or
- present a TLS client certificate intended for the target server to the
proxy.
Code connecting through a plain HTTP proxy does not establish a TLS
connection to the proxy and is not affected by this issue.
##### Remediation
Upgrade to urllib3 2.8.0 or later.
urllib3 2.8.0 independently applies the explicitly configured
`proxy_ssl_context` and proxy-specific certificate assertions to the
HTTPS proxy connection. Target-specific SNI, certificate assertions, and
TLS client certificate parameters are no longer applied to the HTTPS
proxy handshake.
For backward compatibility, when an HTTPS proxy is used with
`use_forwarding_for_https=True` and `proxy_ssl_context` is not provided,
urllib3 2.8.0 continues to use `ssl_context` for the TLS connection to
the proxy. This configuration emits a `FutureWarning`. In urllib3 3.0,
passing `ssl_context` with `use_forwarding_for_https=True` for an HTTPS
proxy will raise an error. Applications should use `proxy_ssl_context`
to configure TLS for an HTTPS forwarding proxy.
The fixes were implemented in commits
b6447295fff7b38fdffc67e0df9712d60cef3cc3 and
07408cec79d1856d81bb42c74a904a24fdb9e465.
#### Severity
- CVSS Score: 7.6 / 10 (High)
- Vector String:
`CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N`
#### References
-
[https://github.com/urllib3/urllib3/security/advisories/GHSA-8988-9cw3-xx77](https://redirect.github.com/urllib3/urllib3/security/advisories/GHSA-8988-9cw3-xx77)
-
[https://nvd.nist.gov/vuln/detail/CVE-2026-97687](https://nvd.nist.gov/vuln/detail/CVE-2026-97687)
-
[https://github.com/urllib3/urllib3/pull/5093](https://redirect.github.com/urllib3/urllib3/pull/5093)
-
[07408cec79)
-
[b6447295ff)
-
[https://github.com/urllib3/urllib3/releases/tag/2.8.0](https://redirect.github.com/urllib3/urllib3/releases/tag/2.8.0)
-
[https://github.com/advisories/GHSA-8988-9cw3-xx77](https://redirect.github.com/advisories/GHSA-8988-9cw3-xx77)
This data is provided by the [GitHub Advisory
Database](https://redirect.github.com/advisories/GHSA-8988-9cw3-xx77)
([CC-BY
4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)).
</details>
---
### urllib3: HTTPResponse.stream()/read_chunked() buffers an unbounded
chunk-size line into memory
[CVE-2026-97689](https://nvd.nist.gov/vuln/detail/CVE-2026-97689) /
[GHSA-vxq7-64xx-v4gw](https://redirect.github.com/advisories/GHSA-vxq7-64xx-v4gw)
<details>
<summary>More information</summary>
#### Details
##### Impact
urllib3's [streaming
API](https://urllib3.readthedocs.io/en/2.7.0/advanced-usage.html#streaming-and-i-o)
is designed for efficiently handling large HTTP responses by reading the
content in chunks, rather than loading the entire response body into
memory at once. When decoding a [chunked-transfer-encoded
response](https://httpwg.org/specs/rfc9112.html#chunked.encoding), this
API reads each chunk's size field by buffering until it sees `\n` or
EOF.
A malicious HTTP server can return `Transfer-Encoding: chunked` and then
send a very long run of bytes without any newline, causing the streaming
client to buffer that entire run before urllib3 can reject the chunk
size as invalid and allocate more memory than intended.
To fix the issue, we'll reject chunk-size fields larger than 65536
bytes, as already done in the non-streaming case, which is currently
handled by the Python standard library. Note that this only applies to
reading the chunk-size field, not the chunk data, which is already
handled correctly. Thus, there shouldn't be any impact for non-malicious
servers.
##### Affected usages
Applications and libraries using urllib3 versions earlier than 2.8.0 may
be affected when streaming a chunked response from untrusted sources.
Specifically, this affects the
[read_chunked()](https://urllib3.readthedocs.io/en/stable/reference/urllib3.response.html#urllib3.response.BaseHTTPResponse.read_chunked)
and
[stream()](https://urllib3.readthedocs.io/en/stable/reference/urllib3.response.html#urllib3.response.BaseHTTPResponse.stream)
methods of the HTTPResponse object.
This also affects requests streaming API, which uses urllib3 under the
hood.
##### Remediation
Upgrade to urllib3 version 2.8.0 or later, where chunk-size fields
larger than 65536 will be rejected. If upgrading is not immediately
possible, consider reading the response at once using the
[read()](https://urllib3.readthedocs.io/en/stable/reference/urllib3.response.html#urllib3.response.BaseHTTPResponse.read)
method.
#### Severity
- CVSS Score: 8.9 / 10 (High)
- Vector String:
`CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H`
#### References
-
[https://github.com/urllib3/urllib3/security/advisories/GHSA-vxq7-64xx-v4gw](https://redirect.github.com/urllib3/urllib3/security/advisories/GHSA-vxq7-64xx-v4gw)
-
[https://nvd.nist.gov/vuln/detail/CVE-2026-97689](https://nvd.nist.gov/vuln/detail/CVE-2026-97689)
-
[cd770b059b)
-
[https://github.com/urllib3/urllib3/releases/tag/2.8.0](https://redirect.github.com/urllib3/urllib3/releases/tag/2.8.0)
-
[https://github.com/advisories/GHSA-vxq7-64xx-v4gw](https://redirect.github.com/advisories/GHSA-vxq7-64xx-v4gw)
This data is provided by the [GitHub Advisory
Database](https://redirect.github.com/advisories/GHSA-vxq7-64xx-v4gw)
([CC-BY
4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)).
</details>
---
### urllib3: Chunked Deflate streaming can enter an infinite loop
[CVE-2026-97688](https://nvd.nist.gov/vuln/detail/CVE-2026-97688) /
[GHSA-gh4c-6fx4-qh6g](https://redirect.github.com/advisories/GHSA-gh4c-6fx4-qh6g)
<details>
<summary>More information</summary>
#### Details
##### Impact
urllib3's streaming API is designed for the efficient handling of large
HTTP responses by reading content in chunks instead of loading the
entire response body into memory at once.
urllib3 can decompress response bodies according to the HTTP
`Content-Encoding` header. When streaming a compressed, chunked
response, urllib3 first consumes data already buffered by the decoder
before reading the next HTTP chunk.
However, urllib3 versions from 2.6.2 through 2.7.0 could enter an
infinite loop when a chunked response contained bytes after the end of
the Deflate stream. If the decompressed body exceeded the requested
streaming chunk size, Python's zlib implementation could retain the
trailing bytes as unconsumed input after reaching the end of the
compressed stream. urllib3 would repeatedly attempt to decode those same
bytes without making progress or reading more data from the network.
A malicious server could exploit this behavior to cause excessive CPU
usage and prevent the affected request from completing on the client.
Network read timeouts would not interrupt the loop because no further
socket operation was required.
##### Affected usages
Applications and libraries using urllib3 versions 2.6.2 through 2.7.0
may be affected when all of the following conditions are met:
1. Compressed responses from an untrusted source are streamed using
`HTTPResponse.stream(amt=N)` or `HTTPResponse.read_chunked(amt=N)` with
a positive, finite chunk size.
2. Content decoding is enabled.
3. The response uses both `Transfer-Encoding: chunked` and
`Content-Encoding: deflate`.
4. The decoded body exceeds the requested chunk size and the encoded
body contains bytes after the end of the Deflate stream.
`HTTPResponse.stream()` uses a finite chunk size by default and is
therefore affected when the other conditions are met.
##### Remediation
Upgrade to urllib3 2.8.0, in which the Deflate decoder stops accepting
input after reaching the end of the compressed stream and no longer
reports trailing bytes as data that can produce more decoded output.
If upgrading is not immediately possible, disable automatic content
decoding for responses from untrusted sources by setting
`decode_content=False`, or reject streamed responses using the Deflate
content encoding. Applications that disable automatic decoding must
handle the compressed response safely at another layer.
#### Severity
- CVSS Score: 6.9 / 10 (Medium)
- Vector String:
`CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N`
#### References
-
[https://github.com/urllib3/urllib3/security/advisories/GHSA-gh4c-6fx4-qh6g](https://redirect.github.com/urllib3/urllib3/security/advisories/GHSA-gh4c-6fx4-qh6g)
-
[https://nvd.nist.gov/vuln/detail/CVE-2026-97688](https://nvd.nist.gov/vuln/detail/CVE-2026-97688)
-
[ea2ad7b21a)
-
[https://github.com/urllib3/urllib3/releases/tag/2.8.0](https://redirect.github.com/urllib3/urllib3/releases/tag/2.8.0)
-
[https://github.com/advisories/GHSA-gh4c-6fx4-qh6g](https://redirect.github.com/advisories/GHSA-gh4c-6fx4-qh6g)
This data is provided by the [GitHub Advisory
Database](https://redirect.github.com/advisories/GHSA-gh4c-6fx4-qh6g)
([CC-BY
4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)).
</details>
---
### Release Notes
<details>
<summary>urllib3/urllib3 (urllib3)</summary>
###
[`v2.8.0`](https://redirect.github.com/urllib3/urllib3/blob/HEAD/CHANGES.rst#280-2026-09-15)
[Compare
Source](https://redirect.github.com/urllib3/urllib3/compare/2.7.0...2.8.0)
\==================
## Security
Fixed the following security issues:
- The TLS configuration for HTTPS proxies could be ignored or
overridden.
(High severity, `GHSA-8988-9cw3-xx77
<https://github.com/urllib3/urllib3/security/advisories/GHSA-8988-9cw3-xx77>`\_\_)
- `HTTPResponse.stream()` and `read_chunked()` could buffer a chunk-size
line of unbounded length in memory. (High severity,
`GHSA-vxq7-64xx-v4gw
<https://github.com/urllib3/urllib3/security/advisories/GHSA-vxq7-64xx-v4gw>`\_\_)
- Chunked Deflate streaming could enter an infinite loop. (Medium
severity,
`GHSA-gh4c-6fx4-qh6g
<https://github.com/urllib3/urllib3/security/advisories/GHSA-gh4c-6fx4-qh6g>`\_\_)
.. caution::
```
urllib3 2.8.0 fixes HTTPS proxy TLS configuration being ignored or
overridden by destination settings. Configurations relying on that
behavior may require changes.
Configure proxy CA certificates and client certificates in
``proxy_ssl_context``, and proxy identity checks with
``proxy_assert_hostname`` or ``proxy_assert_fingerprint``.
Destination client certificates and identity overrides no longer
apply to HTTPS forwarding proxy connections.
```
## Deprecations & Removals
- Deprecated using an empty collection as the `Retry` option
`allowed_methods` to retry any verb.
(`#​5044 <https://github.com/urllib3/urllib3/issues/5044>`\_\_)
## Features
- Added `Url.auth_decoded` and `Url.auth_decoded_joined` convenience
properties to the result of `parse_url()`.
(`#​4945 <https://github.com/urllib3/urllib3/issues/4945>`\_\_)
- Added `basic_auth_encoding` and `proxy_basic_auth_encoding` parameters
to
`urllib3.util.make_headers()`.
(`#​5092 <https://github.com/urllib3/urllib3/issues/5092>`\_\_)
## Bugfixes
- Fixed response header handling to replace obsolete folded header lines
(`obs-fold`) with spaces in accordance with RFC 9112, preventing raw
CRLF
sequences from appearing in header values such as `Set-Cookie`.
(`#​1362 <https://github.com/urllib3/urllib3/issues/1362>`\_\_)
- Fixed usage of `proxy_ssl_context` with `ProxyManager` when
`use_forwarding_for_https=True`. Passing `ssl_context` instead of
`proxy_ssl_context` for HTTPS proxies in this configuration now emits a
`FutureWarning` and will raise an error in v3.0.
(`#​2577 <https://github.com/urllib3/urllib3/issues/2577>`\_\_)
- Changed behavior of the default `ConnectionPool.pool` initialization.
`LifoQueue` is now resolved from the `queue` module after the
`ConnectionPool` is instantiated instead of using the default cached
`QueueCls` class property. This is done because sometimes the
`queue.LifoQueue` is monkey-patched late in the program, such as by
gevent.
(`#​3289 <https://github.com/urllib3/urllib3/issues/3289>`\_\_)
- Raised `UnrewindableBodyError` instead of `ValueError` when retrying a
request whose body had `tell()` but not `seek()`.
(`#​3779 <https://github.com/urllib3/urllib3/issues/3779>`\_\_)
- Decoded percent-encoded SOCKS proxy credentials before authenticating
with
the proxy server.
(`#​3785 <https://github.com/urllib3/urllib3/issues/3785>`\_\_)
- Fixed `HTTPResponse.drain_conn()` to discard unread response data in
64 KiB
chunks (same as the default `amt` when doing
`HTTPResponse.stream(...)`).
(`#​5019 <https://github.com/urllib3/urllib3/issues/5019>`\_\_)
- Fixed `is_ipaddress()` to detect non-standard IPv4 forms accepted by
`socket.connect`, such as hex (`0x7f000001`), octal (`0177.0.0.1`), and
decimal integers (`2130706433`), ensuring SSL certificate verification
uses
the correct mode for these addresses.
(`#​5029 <https://github.com/urllib3/urllib3/issues/5029>`\_\_)
- Fixed `HTTPConnectionPool.urlopen` raising a misleading
`FullPoolError`
instead of `ValueError` when called with an invalid `timeout` argument
on
a pool created with `block=True`.
(`#​5059 <https://github.com/urllib3/urllib3/issues/5059>`\_\_)
- Fixed port-zero handling to preserve explicit `:0` values instead of
substituting the default ports 80 or 443 in URL parsing, pool selection,
proxy configuration, `connection_from_url()`, and HTTP/2 request
authority.
(`#​5071 <https://github.com/urllib3/urllib3/issues/5071>`**,
`#​5101 <https://github.com/urllib3/urllib3/issues/5101>`**)
- Fixed a bug where `PoolManager` passed the `assert_hostname` and
`assert_fingerprint` parameters to HTTP connection pools.
(`#​5077 <https://github.com/urllib3/urllib3/issues/5077>`\_\_)
- Fixed `HTTPConnectionPool.urlopen()` and HTTP proxy forwarding to
strip URL
fragments from absolute request targets before sending requests.
(`#​5079 <https://github.com/urllib3/urllib3/issues/5079>`\_\_)
- Added safeguards to the proxy tunneling code to prevent potential
security
issues when handling invalid characters in the proxy host and HTTP
headers.
This change affects users of Python 3.10, Python 3.11, and Python 3.12
when
the standard library does not contain the fix; those on newer Python
versions
should upgrade to 3.13.14+ or 3.14.5+ to get the same security fixes.
(`#​5091 <https://github.com/urllib3/urllib3/issues/5091>`\_\_)
- Fixed `HTTPSConnection.connect()` overriding
`ProxyConfig.ssl_context`'s
certificate policy and proxy identity checks with the target
connection's TLS
settings when forwarding through an HTTPS proxy.
`HTTPSConnection` no longer applies target SNI, assertions, or client
credentials to forwarding proxy handshakes and continues to use its
`ssl_context` as a fallback when an HTTPS proxy forwards an HTTP target.
(`#​5093 <https://github.com/urllib3/urllib3/issues/5093>`\_\_)
- Fixed URL parsing to more strictly enforce RFC 3986 host syntax,
rejecting
invalid host input such as raw spaces and control characters, malformed
percent-encodings, and percent-encoded control characters in HTTP(S)
hosts
and IPv6 zone identifiers, including proxy CONNECT tunnel targets. Host
normalization now also follows RFC 3986 normalization rules for
percent-encoded octets by decoding percent-encoded unreserved characters
and
uppercasing the hexadecimal digits of retained percent-encoded octets.
(`#​5095 <https://github.com/urllib3/urllib3/issues/5095>`\_\_)
- Fixed an `AttributeError` on Python built with OpenSSL 4+, where
`ssl.PROTOCOL_TLSv1` no longer exists.
(`#​5097 <https://github.com/urllib3/urllib3/issues/5097>`\_\_)
- Fixed `urllib3.contrib.pyopenssl` to use cryptography APIs when
reading a
certificate subject and loading encrypted private keys, avoiding
`DeprecationWarning` raised by pyOpenSSL 26.3.0+.
(`#​5103 <https://github.com/urllib3/urllib3/issues/5103>`\_\_)
- Fixed handling of HTTP 303 redirects for requests with chunked or
file-like
bodies.
(`#​5161 <https://github.com/urllib3/urllib3/issues/5161>`\_\_)
- Fixed `assert_fingerprint()` to raise `SSLError` instead of
`binascii.Error` when a fingerprint has a supported length but contains
non-hexadecimal characters.
(`#​5211 <https://github.com/urllib3/urllib3/issues/5211>`\_\_)
## Misc
- Added a `test` dependency group containing the minimum dependencies
needed
to run the test suite, intended for downstream packagers. The `dev-base`
and `mypy` groups now include this new group via `include-group`,
removing duplication.
(`#​3594 <https://github.com/urllib3/urllib3/issues/3594>`\_\_)
- Fixed test failures with pytest >= 9.1.
(`#​5094 <https://github.com/urllib3/urllib3/issues/5094>`\_\_)
- Enabled JSPI tests with Firefox in the Emscripten test suite.
(`#​5166 <https://github.com/urllib3/urllib3/issues/5166>`\_\_)
- Improved streamed response decoding performance.
(`#​5209 <https://github.com/urllib3/urllib3/issues/5209>`\_\_)
- Fixed flaky tests.
(`#​5232 <https://github.com/urllib3/urllib3/issues/5232>`**,
`#​5234 <https://github.com/urllib3/urllib3/issues/5234>`**,
`#​5239 <https://github.com/urllib3/urllib3/issues/5239>`\_\_)
</details>
---
### Configuration
📅 **Schedule**: (in timezone America/New_York)
- Branch creation
- At any time (no schedule defined)
- Automerge
- At any time (no schedule defined)
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
Release Notes:
- N/A
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC4xMjUuMSIsInVwZGF0ZWRJblZlciI6IjQ0LjEyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
## Why
The Community PR Board route check looks up the configured Track option
by exact name. The mapping for auth-related labels uses `Auth &
Zed.dev`, while the project option is `Auth & zed.dev`, so `route-pr`
fails when it handles those labels.
## What changed
Update the auth-related label mapping to use the existing `Auth &
zed.dev` Track name.
## Testing
- `python3 -m json.tool script/community-pr-track-mapping.json`
- `git diff --check`
Release Notes:
- N/A
# Objective
- This PR enables users to switch between unified/split diff views when
comparing buffers.
- Fixes#64419 .
## Solution
- The unified/split toggle (`DiffStyleControls`) is normally surfaced
automatically by `BufferSearchBar`, which detects any active item
exposing a `SplittableEditor`. That auto-detection is gated to
multi-buffer views, since it's paired with an expand/collapse-all-hunks
control that only makes sense across multiple files. `FileDiffView`
(used by `zed --diff <old> <new>`) is a singleton buffer, so it's
intentionally excluded from that generic path.
- Git's own single-file diff view,
[`SoloDiffView`](395def7a06/crates/git_ui/src/solo_diff_view.rs (L52)),
hits the same limitation and works around it with a small, dedicated
`ToolbarItemView` (`SoloDiffStyleToolbar`) that renders
`DiffStyleControls` directly, independent of `BufferSearchBar`.
- This PR follows the same pattern: a new `FileDiffStyleToolbar` (in
`git_ui_core::file_diff_view`) activates whenever a `FileDiffView` is
the focused pane item, and renders just the unified/split toggle, no
expand/collapse or file-status controls, since neither concept applies
to a plain two-file diff. It's registered in `initialize_pane` alongside
the existing git toolbars.
## Testing
- Did you test these changes? If so, how?
Ran `cargo test -p git_ui_core`, all passed. I've also attached the
results of manual testing in the Showcase section below.
- Are there any parts that need more testing?
I think more tests can be added.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
Adds a unified/split toggle to the diff view opened via `zed --diff
<old> <new>`, matching the toggle already available in git's diff views.
<details>
<summary>Click to view before/after</summary>
**Before**:
<img width="1920" height="1080" alt="screenshot_20260921_020610"
src="https://github.com/user-attachments/assets/92cbcf75-0cac-4555-8d2d-ce927064515f"
/>
**After**:
<img width="1920" height="1080" alt="screenshot_20260921_020355"
src="https://github.com/user-attachments/assets/56f9ebc6-11df-41cc-a44d-99bfa8caa130"
/>
</details>
---
Release Notes:
- Added a unified/split toggle to the diff view opened via `zed --diff
<old> <new>` command.
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
* Preserve bundle compiler flags commit commit is a follow-up to
https://github.com/zed-industries/zed/pull/63432
Linux bundling script had custom `RUSTFLAGS` set which eradicated prior
config.
Moved all flags into `.cargo/bundle-config.toml` instead.
* Trim audio features and compress resources commit removes unused
`rodio` features and enables resource compression
The win from the latter seems not that large, so can revert if needed,
but seemed very easy to enable.
With compiler wrappers disabled, `cargo clean --target-dir
target/binary-size-split-build` and `cargo build --locked -p zed`:
Before: 135.6s wall, 1569.8s CPU, zed binary 1175563800 bytes
After: 130.5s wall (-3.8%), 1488.7s CPU (-5.2%), zed binary 1171527064
bytes (-0.3%, -4.0MB)
With `ZED_BUNDLE=true CXXFLAGS=-stdlib=libc++` and `cargo --config
.cargo/bundle-config.toml build --locked --release -p zed -p cli
--target aarch64-apple-darwin`:
Before: 369.4s wall, 3861.6s CPU, zed binary 381662328 bytes
After: 369.4s wall (+0.01%), 3866.1s CPU (+0.1%), zed binary 377836968
bytes (-1.0%, -3.8MB)
Release Notes:
- N/A
This PR cleans up the repository root a bit, moving some of the less
relevant config files into the `.config` folder and removing unused
ones.
Release Notes:
- N/A
Release notes are the sole information users have about what could
either have improved or have been broken for them. Omitting release
notes is one thing, but not writing any or having empty ones helps
nobody - users get no context on what could cause issues they were
seeing nor do they know about potential improvements, triagers cannot
easily find the PR that could have introduced the bug either.
Thus, this PR now makes it so that danger actually requires one to write
release notes. Empty release notes or the placeholder will no longer be
accepted.
Release Notes:
- N/A
# Objective
Bumps `wasi-sdk` to v34 that is based on LLVM 23.1 which includes [a
compile time and memory usage
fix](https://github.com/llvm/llvm-project/pull/181755) for tree-sitter
grammars. It speeds up every grammar's compile time and reduces compile
memory usage unlocking big grammars that were impossible to compile
before to be submitted to Zed extensions.
Drive-by added additional wasi-sdk targets for the rest of the supported
architectures (by wasi-sdk), if riscv is unwanted I can remove it but it
should not create any problems (I think).
Also noticed the `download-wasi-sdk` script had `OS=mingw` which wasn't
even in the artifact name on v25.
## Testing
Compiled, ran and compiled my [big
grammar](https://github.com/usagi-coffee/tree-sitter-abl) on it, that
wouldn't compile at all pre-llvm 23.
## Self-Review Checklist:
- [X] I've reviewed my own diff for quality, security, and reliability
---
Release Notes:
- Fixed compiling dev extensions with big Tree-sitter grammars.
- Fixed compiling dev extensions on Windows ARM64.
- Added wasi-sdk installation invalidation.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
The particular edge case that is covered here is closing a community PR,
then labeling it with an `area:`, and _then_ reopening it.
Release Notes:
- N/A
It's been fun for a while to have the same function calling GitHub API
in every single script, but we're going to have fun in different ways
now.
This one's for you, @MrSubidubi! 🥂
## Testing
I've ran the things that had `--dry-run` locally and nothing blew up,
but the ultimate smoke test will be carried out in production.
---
Release Notes:
- N/A
We already had the PR's upvotes (all the positive reactions,
deduplicated by user); this commit adds the issue-closed-by-the-PR's
upvotes (deduplicated against the PR's upvoters too). The code got even
uglier because I'm trying to avoid extra API calls.
Release Notes:
- N/A
Not sure if this PR is 100% good, since it removes symbols from local
traces, leaving addresses only — but this what Windows seem to do
already, and we have those symbols on Sentry to restore from, which were
needed to normally read Linux perf traces already (see `perf.zip` in
https://github.com/zed-industries/zed/issues/59689#issuecomment-5452720248)
On the upside, uncompressed binaries' are now ~100MB less, which is a
lot — hence decided to open the PR for the review
-------------------
Strips debug info and local symbols from shipped macOS and Linux
binaries, matching what Windows already does with PDBs: `bundle-mac` now
always runs `dsymutil` before a new `strip -x` step, and `bundle-linux`
adds `--discard-all` plus `zed.dbg`/`remote_server.dbg` extraction via
`--only-keep-debug`.
Sentry uploads are unchanged and precede stripping.
The macOS binary UUID and the GNU build id survive stripping, so
user-provided traces stay recoverable without rebuilding at the
reporter's commit: `sample` output resolves via `atos` against the
archived `zed.dwarf`, and `perf.data` via `perf buildid-cache` against
the Sentry-archived binary.
zed binary:
macOS (2026-08-29 nightly): 420478976 -> 316503984 bytes (-24.7%,
-104.0MB)
Linux (v1.17.2 aarch64): 439417448 -> 336967256 bytes (-23.3%, -102.5MB)
Downloads shrink far less, symbols compress ~7:1: the macOS DMG loses
only ~15MB.
Release Notes:
- Improved installed size on macOS and Linux by stripping debug symbols
from release binaries (roughly -25%)
Improves merge-conflict loading by resolving ordered conflict anchors
with a single excerpt sweep instead of restarting the excerpt scan four
times per conflict.
The pull request also adds `script/generate-merge-conflict-benchmark`,
which creates validated small, medium, or severe repositories with real
unresolved Git merges.
On the severe workload (128 files × 256 conflicts), anchor conversion
decreased from 483.5 ms to 5.9 ms, saving about 478 ms, or roughly 5% of
the total refresh.
Closes
https://linear.app/zed-industries/issue/FR-174/improve-git-panel-performance-for-large-merge-conflicts
## Testing
- `cargo test -p multi_buffer
test_ordered_buffer_anchor_ranges_to_anchor_ranges`
- `cargo test -p git_ui conflict`
- `./script/clippy -p multi_buffer -p git_ui`
- Generated and validated the small synthetic merge-conflict workload
Release Notes:
- Improved performance when opening large merge conflicts
* ensures The Rule cannot be accidentall removed
* fixes the perf command example to capture call graphs, to avoid
round-trips like
https://github.com/zed-industries/zed/issues/59689#issuecomment-5453623044
(samples without call graphs are not quite usable for investigating bugs
like these)
Release Notes:
- N/A
Cargo joins `build.rustflags` across config sources, so the base
`symbol-mangling-version=v0` and `tokio_unstable` flags still apply
after the newly added config.
With sccache disabled, `cargo build --release -p zed` on macOS:
Before: zed binary 420677880 bytes
After: zed binary 375109048 bytes (-10.8%, -45.6MB)
After `strip -x` of both
(https://github.com/zed-industries/zed/pull/63429):
313879024 -> 307727432 bytes (-2.0%, -6.2MB)
The rest of the delta is the smaller symbol table. `drop_glue`
instantiations: 101778 -> 65041.
Release Notes:
- N/A
- Notify the author when their PR has been in draft state with no new
commits for three weeks
- Close the draft PRs that didn't get updated after one more week
- Re-try the cla-bot check on PRs that are still unsigned after a week
- Close the PRs that are still unsigned after the re-try
## Testing
It works on my machine™
```
python script/github-pr-cleanup.py --dry-run
Checking 713 open pull requests
Dry-run mode: no comments or closures will be made
PR #60885: asking the CLA bot to check again
Would comment on PR #60885:
@cla-bot check
PR #61625: asking the CLA bot to check again
Would comment on PR #61625:
@cla-bot check
PR #57239: warning about a stale draft
Would comment on PR #57239:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #57241: warning about a stale draft
Would comment on PR #57241:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61461: warning about a stale draft
Would comment on PR #61461:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61722: warning about a stale draft
Would comment on PR #61722:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61808: warning about a stale draft
Would comment on PR #61808:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61809: warning about a stale draft
Would comment on PR #61809:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
Cleanup complete: 0 unsigned PR closures, 6 draft warnings, 0 draft closures
```
Release Notes:
- N/A
Bundled GLib shadowed the system libraries for host plugins dlopen'd
into the process, like PipeWire's videoconvert on 1.6+, which would
break Wayland screen sharing on newer distros. This PR makes Zed rely on
system GLib instead, since the bundled version pulls from whatever is in
CI (presently Ubuntu 20.04).
Release Notes:
- Removed GLib libraries from Linux release bundle, which could conflict
with system plugins
Release Notes:
- Fixed broken links in the installer Terms of Service dialog (#62677).
---
### Description
Closes#62677
In `script/terms/terms.rtf` and `legal/terms.md` (as well as
`legal/privacy-policy.md` and `legal/third-party-terms.md`), relative
URLs like `/privacy-policy` and `/acceptable-use-policies` caused error
-50 ("The application can't be opened") when clicked from installer
dialogs (such as the macOS installer).
This PR updates the relative URLs to absolute `https://zed.dev` URLs so
they open properly in the browser.
Label | Description
-- | --
area:integrations/git/panel | Feedback for the Git panel UI and
behavior.
area:gpui/graphics/wgpu | Feedback for GPUI's WGPU graphics backend,
including initialization and rendering.
area:breadcrumbs | Feedback for editor path and symbol breadcrumbs.
area:title bar | Issues suitable for title bar.
area:ai/agent thread/checkpoints | Feedback for Agent checkpoint
creation, comparison, restoration, and related Git behavior.
area:ai/agent thread/tools | Feedback for built-in Agent tools,
including execution, permissions, inputs, and outputs.
Release Notes:
- N/A
Our date filter used two qualifiers ("created:>START created:<=END"),
which isn't valid range syntax, so GitHub ignored it and returned every
open issue. Use a single "created:START..END" range. Also fix the window
math, which was a business day too recent and excluded its start day.
Release Notes:
- N/A
# Objective
Prevent successful installations on 32-bit Linux architectures where the
`zed` binary will **fail to execute** post-installation. Rather, fail at
installation time with a proper verdict.
`script/install.sh` maps `uname -m` onto the two architectures Zed
publishes builds for. Two of the matchers named 32-bit userlands and
mapped them onto a 64-bit tarball:
- `linux-armhf` mapped to `aarch64`
- `linux-i686*` mapped to `x86_64`
Neither can execute the binary it selected. Tested on i386 Debian Trixie
container: the installer downloaded, unpacked, symlinked and reported
success, and the failure surfaced later as an exec error -- see
[Showcase](##showcase).
Thus the installer's correct behavior would be to reject the 32-bit
architecture and terminate with an "unsupported" verdict.
## Solution
Remove the case-statement-based mapping of `linux-armhf` to `aarch64`,
and of `linux-i686*` to `x86_64`.
## Testing
Tested in isolation, simulating supported and unsupported platforms, and
supported and unsupported architectures:
| Platform | `uname -m` | Outcome |
| --- | --- | --- |
| Linux | `x86_64` | ✅ Installed — resolves to `x86_64`, symlink created
|
| Linux | `i386` | ❌ Unsupported — `i386` doesn't match glob `x86*` (no
case handles plain i386 anyway |
| Linux | `i686` | ❌ Unsupported — same reason |
| Linux | `aarch64` | ✅ Installed — resolves to `aarch64` |
| Linux | `arm64` | ✅ Installed — resolves to `aarch64` |
| Linux | `armv7l` | ❌ Unsupported — no 32-bit ARM case |
| Linux | `riscv64` | ❌ Unsupported |
| Darwin | `arm64` | ✅ Installed — resolves to `aarch64`, copied to real
`/Applications/Zed.app`, symlink created; |
| Darwin | `x86_64` | ✅ Installed — resolves to `x86_64`, copied to real
`/Applications/Zed.app`, symlink created |
| Darwin | `i386` | ❌ Unsupported — no case for macOS 32-bit |
| FreeBSD | `x86_64` | ❌ Unsupported platform - expected |
This is all correct behavior. Successful installations are expected to
work. Unsupported architectures are detected and rejected as unsupported
during installation.
## Showcase
```plaintext
~# file /usr/bin/dash # a sample executable showing the 32-bit arch
/usr/bin/dash: ELF 32-bit LSB pie executable, Intel i386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=7e2e8652114c8c2ae595b6f78798716a9ba07671, for GNU/Linux 3.2.0, stripped
~# file .local/zed.app/bin/zed
.local/zed.app/bin/zed: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e550eeb1d97f0cdac2460de672bfa36e9e3f6e25, not stripped
~# .local/zed.app/bin/zed
bash: .local/zed.app/bin/zed: cannot execute: required file not found
# It cannot find ELF 64-bit interpreter /lib64/ld-linux-x86-64.so.2 -- this is
# a 32-bit container on a 64-bit host. On a genuine 32-bit host it would fail with:
# `Exec format error`.
```
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Locally conducted tests cover the new/changed behavior
---
Release Notes:
- N/A
GitHub issue search can't express the one filter we want here: "created
at least one business day ago." That's the whole reason the project
board #\87 exists — since we can't save it as a search, we keep a
project's membership in sync to stand in for it.
So: an hourly workflow runs script/github-triage-queue-board.py, which
adds the open issues that fall in the eligibility window to project #\87
and removes the ones that have aged out. Also wires the workflow into
the community automation failure Slack alert, so if it breaks we hear
about it.
Release Notes:
- N/A
Fixes https://github.com/zed-industries/zed/issues/24880
# Objective
"Assisted/analysed by AI"
> The remote_server musl build failed with undefined references to
__isoc23_sscanf and __isoc23_strtol from aws-lc-sys because the default
C compiler used glibc headers while linking against musl libc. Setting
CC_<target>=musl-gcc ensures C dependencies compile with musl headers.
I have tested the fix, and it seems to have fixed the compilation issue
I faced on Fedora 44, without resorting to the [hack noted in
docs](https://zed.dev/docs/development/linux#installing-a-development-build).
Initially reported in this
[issue](https://github.com/zed-industries/zed/issues/24880).
I'd want someone with expertise in the domain to take a look at this
fix, as from what I understand, the process in the doc is a hacky
workaround.
## Solution
Setting CC_<target>=musl-gcc ensures C dependencies compile with musl
headers.
## Testing
- Did you test these changes? If so, how?
<details><summary>Here's my steps to repro:</summary>
1. install [toolbox](https://github.com/containers/toolbox) (or
podman-toolbox)
(I used toolbox as it's easy to reuse the cloned repo, as the whole home
dir is mounted in the devcontainer)
Used the main branch - commit 5d6c88cdb7
2. toolbox create -d fedora -r 44
3. toolbox enter fedora-toolbox-44
4. then run the `scripts/linux` script to install prereqs
5. try compiling remote-server using the commands in
`scripts/install-linux` (I just ran the script wholly)
LDD version:
```
⬢[root@toolbox zed]# ldd --version
ldd (GNU libc) 2.43
```
GCC/MUSL versions:
```
musl-gcc : 1.2.5
gcc : 16.1.1
```
Error:
```
error: linking with `cc` failed: exit status: 1
|
= note: "cc" "-m64"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/rcrt1.o"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crti.o"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crtbeginS.o"
"<747 object files omitted>" "-Wl,--as-needed" "-Wl,-Bstatic"
"/root/zed/target/x86_64-unknown-linux-musl/release/deps/rustceHhjo8/{libzstd_sys-5c3eb6739555ecf4,libtree_sitter_json-ad90c8af7e8a3750,libtree_sitter-f91a92b688e12e56,libwasmtime-decd3377028506ce,libaws_lc_sys-a051f708b6dafc2a,libring-fcc1b43e3092bc93,libpsm-d967f50c6f2b67a4}.rlib"
"-lunwind" "-lc"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-*.rlib"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/deps/rustceHhjo8/raw-dylibs"
"-Wl,-Bdynamic" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack"
"-nostartfiles" "-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/psm-dc603221f407eabc/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/tree-sitter-28f7b87c1db3fab9/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/wasmtime-f0bb0950e09a7352/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/aws-lc-sys-2a7ca8eafafe18fa/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/ring-d7857a166bac60a6/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/zstd-sys-0e04609af7157148/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/tree-sitter-json-b1e2eeaba7bbb519/out"
"-L"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained"
"-L" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib" "-o"
"/root/zed/target/x86_64-unknown-linux-musl/release/deps/remote_server-3782b255c59d4e14"
"-Wl,--gc-sections" "-static-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1"
"-nodefaultlibs" "-Wl,--disable-new-dtags,-rpath,$ORIGIN/../lib"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crtendS.o"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crtn.o"
= note: some arguments are omitted. use `--verbose` to show all linker
arguments
= note: /usr/bin/ld.bfd:
/root/zed/target/x86_64-unknown-linux-musl/release/deps/rustceHhjo8/libaws_lc_sys-a051f708b6dafc2a.rlib(f8e4fd781484bd36-bcm.o):
in function `aws_lc_0_40_0_handle_cpu_env':
/aws-lc/crypto/fipsmodule/cpucap/cpu_intel.c:(.text.aws_lc_0_40_0_handle_cpu_env+0x63):
undefined reference to `__isoc23_sscanf'
/usr/bin/ld.bfd:
/root/zed/target/x86_64-unknown-linux-musl/release/deps/rustceHhjo8/libaws_lc_sys-a051f708b6dafc2a.rlib(f8e4fd781484bd36-bcm.o):
in function `pkey_rsa_ctrl_str':
/aws-lc/crypto/fipsmodule/evp/p_rsa.c:692:(.text.pkey_rsa_ctrl_str+0x222):
undefined reference to `__isoc23_strtol'
/usr/bin/ld.bfd:
/aws-lc/crypto/fipsmodule/evp/p_rsa.c:703:(.text.pkey_rsa_ctrl_str+0x261):
undefined reference to `__isoc23_strtol'
collect2: error: ld returned 1 exit status
= note: some `extern` functions couldn't be found; some native libraries
may need to be installed or have their path specified
= note: use the `-l` flag to specify native libraries to link
= note: use the `cargo:rustc-link-lib` directive to specify the native
libraries to link with Cargo (see
https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-link-lib)
error: could not compile `remote_server` (bin "remote_server") due to 1
previous error
```
</details>
- Are there any parts that need more testing? -- Maybe
- How can other people (reviewers) test your changes? Is there anything
specific they need to know? -- Steps listed above
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test? -- Fedora 44
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
## Showcase
> This section is optional. If this PR does not include a visual change
or does not add a new user-facing feature, you can delete this section.
- Help others understand the result of this PR by showcasing your
awesome work!
- If this PR includes a visual change, consider adding a screenshot,
GIF, or video
- A before/after comparison is very useful for changes to existing
features!
While a showcase should aim to be brief and digestible, you can use a
toggleable section to save space on longer showcases:
<details>
<summary>Click to view showcase</summary>
My super cool demos here
</details>
---
Release Notes:
- Fixed musl error when building remote server from source for the
default musl triple on Linux
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
`priority:*` labels in the github repository are becoming `severity:*`,
and `frequency:*` — `reach:*`. This commit will update the slack
notifications for the first responders accordingly.
Also, delete the github-label-issues-to-triage.py one-off script, which
worked with the old label names and is by now too distant in the past to
be useful as reference or anything.
Release Notes:
- N/A
Rei-mplements the logic from
9552acc2bc/script/bundle-mac (L120-L123)
for Windows bundling so that `run-bundling` label in CI can build
unsigned Windows binaries properly.
Release Notes:
- N/A
## Summary
- Upgrade sccache from 0.10.0 to 0.16.0 on macOS, Linux, and Windows CI
runners.
- Normalize the GitHub workspace with `SCCACHE_BASEDIRS` so identical
builds can reuse cache entries across checkout roots.
- Validate the cached binary version and stop an older server before
replacing it, including on Windows where a running executable cannot be
overwritten.
## Why
The setup scripts configured `SCCACHE_BASEDIR`, which sccache did not
use for cache-key path normalization. Absolute checkout paths therefore
remained part of cache keys and reduced reuse between CI workspaces.
sccache 0.16.0 supports `SCCACHE_BASEDIRS` and includes the Windows
path-normalization fix needed for the Windows runner.
## Validation
- `bash -n script/setup-sccache`
- `git diff --check`
- Upgraded a live local sccache 0.15.0 server to 0.16.0 through the
setup script.
- Compiled identical C sources from two checkout roots and observed one
cache miss followed by one cache hit.
- Confirmed that every release asset referenced by the setup scripts
exists for the supported CI runner targets.
Release Notes:
- N/A
script/linux tried to install dev-util/cmake, which is not the correct
package name, so the script fails. Changing it to dev-build/cmake fixes
this.
Release Notes:
- N/A
Automates the Guild contributor program on project board #74 so the
cohort is recognized and kept unblocked without manual babysitting.
- Move a board issue to In Progress when a Guild member self-assigns it,
and post a friendly heads-up when they are assigned an issue that is not
on the board.
- Flag when a Guild member opens a new PR while another of theirs is
still open, to help them land work before spreading thin.
- Check in on quiet assignments and, if an assignee stays silent, free
the issue back to a to-do column so others can pick it up; a "guild
hold" label lets maintainers pause check-ins after they have followed
up.
- Share a weekly digest of what the Guild shipped.
- Label PRs from Guild members and recognize a Guild contributor tier on
the community PR board.
Release Notes:
- N/A
