staging/svanheule/include, branch main

prereq-build/u-boot: add Python 3.14 support

2026-06-16T10:51:01Z

Python 3.14 is the default version on Fedora 43/44. Signed-off-by: Etienne Champetier Link: https://github.com/openwrt/openwrt/pull/23243 Signed-off-by: Test Dev

prereq-build: add clang support

2026-06-16T08:56:46Z

The Apple g++ check is really clang in disguise. Furthermore, testing on Linux hosts reveals that clang can sufficiently replace gcc. Minimum version of clang is 12 because of ccache. Signed-off-by: Rosen Penev Link: https://github.com/openwrt/openwrt/pull/17259 Signed-off-by: Jonas Jelonek

build: fixup version.date creation for source archives

2026-06-12T15:41:09Z

Published sources archives may contain a mixture of MTIMEs, so taking the time of the first file found varies based on filesystem order. To fix this, sort all MTIMEs and take the latest. Since piping into a file directly creates that file, we also need to specifically tell `find` to ignore `version.date`. Furthermore, move this prior to the ./src copy step, since for some packages, the OpenWrt build system ships extra ./src files, which would introduce the wrong timestamps again. Fix: e36c2946b7b build: derive PKG_SOURCE_DATE_EPOCH from the unpacked source tree Link: https://github.com/openwrt/openwrt/pull/23756 Signed-off-by: Paul Spooren

prereq-build: increase GCC requirement to 10

2026-06-10T09:43:38Z

With ccache 4.13, it mandates a minimum of 10. Fixes: 84cb042e3a8e ("tools/ccache: update to 4.13.3") Signed-off-by: Rosen Penev Link: https://github.com/openwrt/openwrt/pull/23718 Signed-off-by: Robert Marko

prereq-build: bump python requirement to 3.8

2026-06-10T07:00:33Z

Even though 3.8 is quite old, it's still used by Ubuntu 20.04 LTS. Bump the version to get some extra features. Signed-off-by: Rosen Penev Link: https://github.com/openwrt/openwrt/pull/23521 Signed-off-by: Jonas Jelonek

build: fix recipe line break in wrap_mirror fallback path

2026-06-04T19:12:27Z

Commit 042996b46b ("build: stricter hash validation on download") refactored the $(if) in wrap_mirror from a single line to multiple lines. The else branch (used when MIRROR is empty) was moved to a new line without a trailing backslash on the preceding line. This causes download methods that use wrap_mirror (e.g. git) to fail when PKG_SOURCE_MIRROR is 0: SHELL= flock ...flock -c ' ... bash: -c: line 1: unexpected EOF while looking for matching `'' The fix is to add the missing \ to the else branch. Signed-off-by: Karsten Sperling

kernel: don't disable stack validation in cross builds

2026-06-04T18:00:36Z

c3e31b6a9b04 (2019-07-03), 5f8e5872406d (2019-10-02), and 802bfe080678 (2022-10-20) disabled kernel stack validation when the build host was not running Linux, as the objtool kernel build tool required for stack validation was not portable to other build host environments. This is no longer true, and it is not necessary to attempt to disable kernel stack validation any longer. Signed-off-by: Mark Mentovai Link: https://github.com/openwrt/openwrt/pull/23612 Signed-off-by: Robert Marko

build: derive PKG_SOURCE_DATE_EPOCH from the unpacked source tree

2026-06-02T09:51:00Z

Previously PKG_SOURCE_DATE_EPOCH came from a git log on the OpenWrt package directory. That fails in shallow feed clones and in the SDK (no .git), collapsing to the script's mtime and breaking .apk reproducibility across SDK rebuilds and between buildbot and SDK. With this comment, PKG_UNPACK generates a version.date file, later used to determine a reproducible SOURCE_DATE_EPOCH. Since unpack happens after download, the evaluation of SOURCE_DATE_EPOCH is now lazy, invoking the `get_source_date_epoch.sh` script on every use. While at it, drop export of PKG_SOURCE_DATE_EPOCH and clean it from the ipkg-build script. Link: https://github.com/openwrt/openwrt/issues/21579 Link: https://github.com/openwrt/openwrt/pull/21587 Co-Authored-By: Claude Opus 4.7 (1M context) Link: https://github.com/openwrt/openwrt/pull/23576 Signed-off-by: Paul Spooren

image: fix per device targz rootfs wrong suffix and redundant images

2026-05-29T11:10:23Z

In commit d89cb72c23fea53883c1e6203020d9b555208452 , a new rootfs type "targz" was introduced, to correctly pack the rootfs AFTER `DEVICE_PACKAGES` installation (unlike the old simple `rootfs.tar.gz`) . The expected release artifact shall be a single corresponding tar gz release accompanying or relacing the old simple `rootfs.tar.gz`. However, if one take a look at the v25.12 series release download pages, e.g. [25.12.4/x86/64](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/), one could see that there're now four release artifacts related to rootfs targz: - [generic-targz-combined-efi.img.gz](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-generic-targz-combined-efi.img.gz) - [generic-targz-combined.img.gz](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-generic-targz-combined.img.gz) - [generic-targz-rootfs.img.gz](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-generic-targz-rootfs.img.gz) - [rootfs.tar.gz](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-rootfs.tar.gz) It's obvious the new `targz` release actually reuses the same `TARGET_ROOTFS_{TYPE}` handler same as `squashfs`, `ext4` and alike. And the three `generic-targz` img.gz contains the same expected tar gz either as their second partition, or as the whole image. This could be verified by the following script: ```bash URL_PARENT=https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64- for TYPE in combined-efi combined rootfs; do curl -L "${URL_PARENT}generic-targz-${TYPE}.img.gz" | gzip -cd > "${TYPE}.img" done for TYPE in combined-efi combined; do INFO=$(sfdisk -d "${TYPE}.img" | sed -n 's/^'"${TYPE}.img"'2 : start= \+$[0-9]\+$, size= \+$[0-9]\+$,.\+.\+$/\1 \2/p') dd if="${TYPE}.img" of="${TYPE}.tar.gz" bs=512 skip="${INFO%% *}" count="${INFO##* }" done cp rootfs.img rootfs.tar.gz sha256sum combined-efi.tar.gz combined.tar.gz rootfs.tar.gz file rootfs.tar.gz ``` Output: ```log % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 13.12M 100 13.12M 0 0 194.6M 0 0 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 12.93M 100 12.93M 0 0 190.9M 0 0 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 7.13M 100 7.13M 0 0 257.6M 0 0 GPT PMBR size mismatch (246304 != 246334) will be corrected by write. The backup GPT table is corrupt, but the primary appears OK, so that will be used. The backup GPT table is not on the end of the device. 212992+0 records in 212992+0 records out 109051904 bytes (109 MB, 104 MiB) copied, 0.258064 s, 423 MB/s 212992+0 records in 212992+0 records out 109051904 bytes (109 MB, 104 MiB) copied, 0.261621 s, 417 MB/s 18b98d3562dc3067ae095ee44d4ff3158cf84e89063c3df66c0ef6638922ba71 combined-efi.tar.gz 18b98d3562dc3067ae095ee44d4ff3158cf84e89063c3df66c0ef6638922ba71 combined.tar.gz 18b98d3562dc3067ae095ee44d4ff3158cf84e89063c3df66c0ef6638922ba71 rootfs.tar.gz rootfs.tar.gz: gzip compressed data, max compression, from Unix, original size modulo 2^32 0 ``` The checksum of the extracted, actually expected .tar.gz are all same. And if we peek inside its content, it's indeed what we expected: ``` > tar -tzf rootfs.tar.gz ./ ./bin/ ./bin/ash ./bin/board_detect ./bin/busybox ./bin/cat ./bin/chgrp ./bin/chmod ./bin/chown ./bin/config_generate ./bin/cp ./bin/date ... ``` A disk image with a `tar.gz` as its second partiton doesn't boot anyway and I doubt if there's any mechanic to make it bootable. So `generic-targz-combined-efi.img.gz` and `generic-targz-combined.img.gz` are not needed at all, and `generic-targz-rootfs.img.gz` shall be renamed to have a `tar.gz` suffix instead. Therefore work around this by skipping creating images for fs `targz` in the general loop, and only create the rootfs.tar.gz later for `targz` "fs" This affects both the real builder and imagebuilder. I've tested this with multiple imagebuilders. Tested with `openwrt-imagebuilder-25.12.4-mvebu-cortexa53.Linux-x86_64`: ```sh rm -rf bin && make image PROFILE=generic ``` Without the fix: ``` > tree bin/ bin/ └── targets └── x86 └── 64 ├── openwrt-25.12.4-x86-64-generic.bom.cdx.json ├── openwrt-25.12.4-x86-64-generic-ext4-combined-efi.img.gz ├── openwrt-25.12.4-x86-64-generic-ext4-combined.img.gz ├── openwrt-25.12.4-x86-64-generic-ext4-rootfs.img.gz ├── openwrt-25.12.4-x86-64-generic-kernel.bin ├── openwrt-25.12.4-x86-64-generic.manifest ├── openwrt-25.12.4-x86-64-generic-rootfs.tar.gz ├── openwrt-25.12.4-x86-64-generic-squashfs-combined-efi.img.gz ├── openwrt-25.12.4-x86-64-generic-squashfs-combined.img.gz ├── openwrt-25.12.4-x86-64-generic-squashfs-rootfs.img.gz ├── openwrt-25.12.4-x86-64-generic-targz-combined-efi.img.gz ├── openwrt-25.12.4-x86-64-generic-targz-combined.img.gz ├── openwrt-25.12.4-x86-64-generic-targz-rootfs.img.gz ├── profiles.json └── sha256sums ``` With the fix: ``` > tree bin/ bin/ └── targets └── x86 └── 64 ├── openwrt-25.12.4-x86-64-generic.bom.cdx.json ├── openwrt-25.12.4-x86-64-generic-ext4-combined-efi.img.gz ├── openwrt-25.12.4-x86-64-generic-ext4-combined.img.gz ├── openwrt-25.12.4-x86-64-generic-ext4-rootfs.img.gz ├── openwrt-25.12.4-x86-64-generic-kernel.bin ├── openwrt-25.12.4-x86-64-generic.manifest ├── openwrt-25.12.4-x86-64-generic-rootfs.tar.gz ├── openwrt-25.12.4-x86-64-generic-squashfs-combined-efi.img.gz ├── openwrt-25.12.4-x86-64-generic-squashfs-combined.img.gz ├── openwrt-25.12.4-x86-64-generic-squashfs-rootfs.img.gz ├── openwrt-25.12.4-x86-64-generic-targz-rootfs.tar.gz ├── profiles.json └── sha256sums ``` And with `openwrt-imagebuilder-25.12.4-mvebu-cortexa53.Linux-x86_64`: ```sh rm -rf bin && make image PROFILE=ripe_atlas-v5 ``` Without the fix: ``` > tree bin/ bin/ └── targets └── mvebu └── cortexa53 ├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5.bom.cdx.json ├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-ext4-sdcard.img.gz ├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5.manifest ├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-rootfs.tar.gz ├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-squashfs-sdcard.img.gz ├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-targz-sdcard.img.gz ├── profiles.json └── sha256sums ``` With the fix: ``` > tree bin/ bin/ └── targets └── mvebu └── cortexa53 ├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5.bom.cdx.json ├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-ext4-sdcard.img.gz ├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5.manifest ├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-rootfs.tar.gz ├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-squashfs-sdcard.img.gz ├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-targz-rootfs.tar.gz ├── profiles.json └── sha256sums ``` Signed-off-by: Guoxin Pu Link: https://github.com/openwrt/openwrt/pull/23570 Signed-off-by: Robert Marko

build: fix apk_package_files wildcard for packages without ABI version

2026-05-22T12:54:34Z

The wildcard combined an apk_package_files pattern of $(pkg)-*.apk with a gen_package_wildcard that ends in [^a-z]*, so the full glob required two dashes. Files for packages without an ABI version (e.g. ubbf-0~....apk) only contain one dash and never matched, so ipkg-remove was never called on them and stale .apk files accumulated in the bin directory. Drop the explicit dash from apk_package_files. The [^a-z] in gen_package_wildcard already serves as the dash matcher, and scripts/ipkg-remove filters precisely by reading apk metadata. Fixes: 642d568b0f0a ("build: fix ipkg-remove: add support for removing apk files") Signed-off-by: Felix Fietkau