iwd: drop the stale version pin that ships 3.9 as 3.10 - #3176
Open
xiaodoudou wants to merge 1 commit into
Open
Conversation
The override pins PKG_VERSION to 3.10 but carries the sha256 of iwd-3.9.tar.xz, copied from the base package when the pin was added. kernel.org's signed sha256sums.asc lists, for iwd-3.9.tar.xz: 0cd7dc9b32b9d6809a4a5e5d063b5c5fd279f5ad3a0bf03d7799da66df5cad45 and for iwd-3.10.tar.xz: 640bff22540e1714f71772a83123aff6f810b7eb9d7d6df1e10fb2695beb5115 That mismatch has not been failing builds, it has been downgrading them. get_archive fetches the real 3.10 from kernel.org, rejects it on the checksum with a warning, and falls back to the distribution-sources mirror, whose iwd-3.10.tar.xz is byte identical to iwd-3.9.tar.xz: same 1117304 bytes, same sha, unpacks to iwd-3.9/. That copy matches the stale checksum, extract strips the top level directory so the name never gives it away, and every device ships 3.9 labelled 3.10. The pin has also outlived its purpose. It was added when the base package was on 3.9; the base is now on 3.12 with a checksum that does match kernel.org, so the override holds us behind instead of ahead. Dropping the two lines lets it follow the base package again and removes the second copy that drifted in the first place. 3.9 to 3.12 is bug fixes only: BSS TM neighbor reports, deauth and FT association failure, roaming with stale frequencies, interface registration before acquiring the name, PMKSA expiration and an uninitialized PMKID buffer. src/iwd.config.rst is byte identical, so every key in our main.conf still applies, the configure option set is unchanged, ell stays bundled, and src/iwd.service.in is untouched.
xiaodoudou
force-pushed
the
iwd-drop-stale-version-pin
branch
from
August 13, 2026 11:18
f52c3f7 to
4d2c43b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Our iwd override pins
PKG_VERSION="3.10"but carries the sha256 ofiwd-3.9.tar.xz. The pin came in with #2079 and the checksum was copied from the base package, which was on 3.9 at the time. kernel.org's signedsha256sums.ascinpub/linux/network/wireless/:That mismatch does not fail the build, it downgrades it.
scripts/get_archivetriesPKG_URLfirst, gets the real 3.10 tarball from kernel.org, computes640bff22..., printsWARNING Incorrect checksum calculated on downloaded fileand throws it away. It then falls back to${DISTRO_MIRROR}/iwd-3.10.tar.xz, and that file on distribution-sources is byte identical toiwd-3.9.tar.xz: same 1117304 bytes, same0cd7dc9b..., unpacks toiwd-3.9/. It matches the stale checksum, so it is accepted.scripts/extractthen untars with--strip-components=1into a directory it namesiwd-3.10, so the tarball's real version never surfaces anywhere.The result is that the package metadata says 3.10, the base package says 3.12, and every shipping device is running iwd 3.9.
iwd --versionon an image confirms it. The only trace is that one warning line in the build log.The pin has also outlived its purpose. It was added to get ahead of a base package that was on 3.9; the base is now on 3.12 with a checksum that does match kernel.org, so the override holds us two releases behind instead of ahead. Deleting the two lines restores what #2079 was after and removes the second copy of version and checksum that drifted in the first place.
Testing
The checksum claims were verified against upstream rather than taken from either file: iwd 3.9, 3.10, 3.11 and 3.12 downloaded from
https://www.kernel.org/pub/linux/network/wireless/and hashed locally, then cross-checked against the PGP-signedsha256sums.ascin the same directory. The mirror copy atdistribution-sources/releases/download/sources/iwd-3.10.tar.xzwas downloaded and confirmed to be the 3.9 tarball. The 3.9 and 3.12 trees were unpacked and diffed for anything that touches how we build or configure iwd.Checksums line up as quoted above, and the base package's
d89a5e45...is the genuine 3.12. The mirror'siwd-3.10.tar.xzhashes to0cd7dc9b...and unpacks toiwd-3.9/, which is what has been masking the mismatch.3.9 to 3.12 is four bug fix releases with nothing else in them:
-std=c23Diffing the two trees:
src/iwd.config.rstis byte identical, so every key in ourmain.confstill applies; theAC_ARG_ENABLEset is unchanged, so our configure line still applies; ell is bundled in both with the same minimum version, so no dependency bump;src/iwd.service.inis unchanged, and we replace the unit anyway.Additional Context
A few of those fixes land where our hardware hurts. FT association failure and roaming with stale frequencies are in the reassociation path, and PMKSA caching is what should let a wake skip the full handshake, which is relevant to the long reconnect after resume on the Qualcomm devices.
One thing this PR cannot fix: distribution-sources still hosts an
iwd-3.10.tar.xzthat is really 3.9. Nothing fetches it once this lands, but it is worth replacing or deleting so it cannot mask another checksum mismatch later.If you would rather not move three releases at once, the conservative alternative is to keep the pin and correct it to
PKG_SHA256="640bff22540e1714f71772a83123aff6f810b7eb9d7d6df1e10fb2695beb5115". That still moves the devices off 3.9, since that is what they run today, and leaves the same drift in place for the next base bump.AI Usage
While ROCKNIX doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it
helps set the right context for reviewers.
Did you use AI tools to help write this code? YES
Yes. AI was used to verify the checksums against kernel.org, trace the mirror fallback and write the change.