librespeed: fix the kconfig recursion between common and the clients by BKPepe · Pull Request #30468 · openwrt/packages

BKPepe · 2026-09-07T11:34:26Z

Fixes the recursive dependency kconfig reports since librespeed-common was merged:

symbol PACKAGE_librespeed-cli-rust depends on PACKAGE_librespeed-cli
symbol PACKAGE_librespeed-cli is selected by PACKAGE_librespeed-common
symbol PACKAGE_librespeed-common depends on PACKAGE_librespeed-cli-rust

librespeed-cli-rust provided the name of a real package, so librespeed-cli
had two providers. For a + dependency on such a name, package-metadata.pl
re-emits the default provider's architecture gate under a condition that names
the consuming package, which kconfig reads as a self-dependency. The same error
is minted again for luci-app-librespeed.

The provide becomes virtual and unversioned, as package-pack.mk requires for
cross-package provides, and librespeed-common names a client directly instead
of resolving through the shared name. Both architecture gates are inherited
from the clients, so no list is repeated:

depends on !(!PACKAGE_librespeed-cli) || (<rust arch list>)
depends on !(PACKAGE_librespeed-cli) || (<go arch list>)
select PACKAGE_librespeed-cli-rust if !PACKAGE_librespeed-cli

Verified in the same SDK container the CI uses, with the whole feed mounted the
way the CI mounts it: no recursion, librespeed-common is enabled and built on
both powerpc_8548 (which picks librespeed-cli-rust, the only client that builds
there) and x86_64 (which picks librespeed-cli). The packaged metadata collapses
the conditional to a single client per architecture.

Approaches that were measured and rejected: dropping the + leaves the package
unselectable, and the SDK then logs "Skipping librespeed-common due to
unsupported architecture" on powerpc. Moving CONFLICTS to librespeed-cli breaks
the three-way loop but leaves the direct self-dependency, because that comes
from resolving a name with two providers rather than from CONFLICTS.

CONFLICTS stays: both packages install /usr/bin/librespeed-cli.

Add a common backend for running librespeed-cli measurements on a router. The package provides a locked measurement runner, live progress state, and an rpcd ucode plugin exposing start/stop/status/result/history/config over ubus. Scheduled measurements are managed through cron and can run within a configurable time window. Optional daily aggregation keeps longer-term history compact. Raw measurements are kept in JSONL for a configurable retention period. When persistent archive storage is configured, completed days are reduced to daily min/avg/max values. Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>

Copilot

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Pull request overview

Resolves a Kconfig recursive dependency involving librespeed-common, librespeed-cli, and librespeed-cli-rust by changing librespeed-common to depend on the client rather than select it.

Changes:

Bumps PKG_RELEASE to reflect the dependency metadata change.
Replaces +librespeed-cli with librespeed-cli in DEPENDS to avoid select-based recursion.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

openwrt-ai

Reviewed 1 new commit.

Generated by Claude Code

openwrt-ai · 2026-09-07T12:04:34Z

  CATEGORY:=Utilities
  TITLE:=LibreSpeed measurement orchestration
-  DEPENDS:=+librespeed-cli +rpcd-mod-ucode +jsonfilter +ucode +ucode-mod-fs \
+  DEPENDS:=librespeed-cli +rpcd-mod-ucode +jsonfilter +ucode +ucode-mod-fs \


Without the +, metadata generation emits depends on PACKAGE_librespeed-cli||PACKAGE_librespeed-cli-rust, so the symbol is unselectable until one of the clients is enabled by hand — a bare CONFIG_PACKAGE_librespeed-common=m (SDK test builds, or a future +librespeed-common from luci-app-librespeed, which the package description already points at) gets silently dropped by make defconfig. Is losing the automatic pull-in of a client the intended trade-off here?

Generated by Claude Code

fixed, thanks — solved by keeping the + and splitting the client per architecture instead.

Generated by Claude Code

map-b · 2026-09-07T12:35:46Z

As alternative, could you try defining the CONFLICTS in the other side (the kconfig's default provider in lexicographical scan order: librespeed-cli)? Excuse me for not trying it myself.

openwrt-ai

Reviewed 1 new commit.

Generated by Claude Code

openwrt-ai · 2026-09-08T05:30:07Z

 PKG_LICENSE_FILES:=LICENSE

 include $(INCLUDE_DIR)/package.mk
+include ../../lang/golang/golang-values.mk


nit: this is the only include of golang-values.mk outside lang/golang itself, and the $(GO_ARCH_DEPENDS:@%=%) on line 25 depends on that variable keeping its @ prefix — drop the @ upstream and the substitution silently yields +@(...):librespeed-cli, which mconf_depends then emits as a bare select (aarch64||...). A one-line comment here on why the Go arch list is borrowed would make that coupling visible to the next person touching either file.

Generated by Claude Code

fixed, thanks — solved by dropping the golang-values.mk include and the substitution entirely.

Generated by Claude Code

librespeed-cli-rust provided the name of a real package, so librespeed-cli had two providers. package-metadata.pl answers a '+' dependency on such a name by re-emitting the default provider's architecture gate under a condition that names the consuming package, so librespeed-common came out depending on itself and kconfig rejected the feed as soon as it was installed. luci-app-librespeed inherited the same error. Provide a virtual name instead, unversioned, as package-pack.mk requires for cross-package provides, and let librespeed-common name a client directly: the Go one where it is enabled, the Rust port otherwise. Both architecture gates are inherited from the clients, so neither list is repeated here. Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>

openwrt-ai

Reviewed 1 new commit.

Generated by Claude Code

openwrt-ai · 2026-09-09T01:42:52Z

+  DEPENDS:=+PACKAGE_librespeed-cli:librespeed-cli \
+	+!PACKAGE_librespeed-cli:librespeed-cli-rust \


The Go branch contributes no select at all: select PACKAGE_librespeed-cli if PACKAGE_librespeed-cli is dropped by next if $depend eq $condition; at package-metadata.pl:225, so only the !PACKAGE_librespeed-cli → rust select survives and a bare CONFIG_PACKAGE_librespeed-common=y pulls librespeed-cli-rust on every architecture, x86_64 included. The PR body's "x86_64 (which picks librespeed-cli)" holds only when something else already enabled the Go client. Is making the Rust port the default on Go-capable targets intended?

Generated by Claude Code

openwrt-ai · 2026-09-09T01:42:59Z

  URL:=https://github.com/BKPepe/speedtest-cli-rust
  DEPENDS:=$(RUST_ARCH_DEPENDS) +libopenssl
-  PROVIDES:=librespeed-cli
+  PROVIDES:=@librespeed-cli-any


Nothing in this feed or in luci requires librespeed-cli-any — librespeed-common now names both clients directly — and neither provider sets DEFAULT_VARIANT:=1, which package-pack.mk:208 requires for a cross-package virtual provide (both get provider priority "" under apk). Either drop the line, or mark librespeed-cli as the default provider the way acme-acmesh does for @acme.

Generated by Claude Code

map-b · 2026-09-09T10:24:09Z

Mmh so the specialness of this/these cases are the DEPENDS on @(arch constraints) (DEPENDS:=$({GO,RUST}_ARCH_DEPENDS)), the special handling of @ in depends. And only for the multi-provided-by virtual names are in the game.

That seems like a bug, doesnt it? that common depends on common cycle.

After a hard time I think I(we, agent) got something that could be useful. Basically the kconfig metadata generation was mixing the provider-selection logic, when there are multiple provider logic involved, with the handling of @-special semantic.

And this proposal seems reasonable to me. And it would allow us to avoid this extra limitation in cases like this librespeed-common one (Go and Rust dependencies with its @(archs) contraints and multi-provider provides cases).

package-metadata: drop self-referencing rank from depends-on gates openwrt#25091

Web UI for librespeed-cli measurements: a Test page with live progress and a quick 24-hour chart, a History page with filters, a large chart and CSV/JSON export, and Settings for scheduling and history retention. Uses the librespeed-common rpcd backend. Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>

Copilot AI lite review requested due to automatic review settings September 7, 2026 11:34

BKPepe force-pushed the librespeed-common-kconfig branch from 178cfcf to c82d645 Compare September 7, 2026 11:36

Copilot AI reviewed Sep 7, 2026

View reviewed changes

Copilot started reviewing on behalf of BKPepe September 7, 2026 11:53 View session

openwrt-ai reviewed Sep 7, 2026

View reviewed changes

BKPepe force-pushed the librespeed-common-kconfig branch from c82d645 to 32afec4 Compare September 7, 2026 20:40

BKPepe changed the title ~~librespeed-common: require the client instead of selecting it~~ librespeed: fix the kconfig recursion between common and the clients Sep 7, 2026

openwrt-ai reviewed Sep 8, 2026

View reviewed changes

BKPepe force-pushed the librespeed-common-kconfig branch from 32afec4 to c606f05 Compare September 9, 2026 00:14

openwrt-ai reviewed Sep 9, 2026

View reviewed changes

map-b mentioned this pull request Sep 9, 2026

package-metadata: drop self-referencing rank from depends-on gates openwrt/openwrt#25091

Open

BKPepe marked this pull request as draft September 9, 2026 10:50

Navigation Menu

Uh oh!

librespeed: fix the kconfig recursion between common and the clients - #30468

librespeed: fix the kconfig recursion between common and the clients#30468
BKPepe wants to merge 1 commit into
openwrt:masterfrom
BKPepe:librespeed-common-kconfig

BKPepe commented Sep 7, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

openwrt-ai left a comment

Uh oh!

openwrt-ai Sep 7, 2026

Uh oh!

openwrt-ai Sep 8, 2026

Uh oh!

map-b commented Sep 7, 2026

Uh oh!

openwrt-ai left a comment

Uh oh!

openwrt-ai Sep 8, 2026

Uh oh!

openwrt-ai Sep 9, 2026

Uh oh!

openwrt-ai left a comment

Uh oh!

openwrt-ai Sep 9, 2026

Uh oh!

openwrt-ai Sep 9, 2026

Uh oh!

map-b commented Sep 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

		DEPENDS:=+PACKAGE_librespeed-cli:librespeed-cli \
		+!PACKAGE_librespeed-cli:librespeed-cli-rust \

Uh oh!

Conversation

BKPepe commented Sep 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

openwrt-ai left a comment

Choose a reason for hiding this comment

Uh oh!

openwrt-ai Sep 7, 2026

Choose a reason for hiding this comment

Uh oh!

openwrt-ai Sep 8, 2026

Choose a reason for hiding this comment

Uh oh!

map-b commented Sep 7, 2026

Uh oh!

openwrt-ai left a comment

Choose a reason for hiding this comment

Uh oh!

openwrt-ai Sep 8, 2026

Choose a reason for hiding this comment

Uh oh!

openwrt-ai Sep 9, 2026

Choose a reason for hiding this comment

Uh oh!

openwrt-ai left a comment

Choose a reason for hiding this comment

Uh oh!

openwrt-ai Sep 9, 2026

Choose a reason for hiding this comment

Uh oh!

openwrt-ai Sep 9, 2026

Choose a reason for hiding this comment

Uh oh!

map-b commented Sep 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

BKPepe commented Sep 7, 2026 •

edited

Loading