release-targets: drop mesa-vpu from auto-attached extensions#302
release-targets: drop mesa-vpu from auto-attached extensions#302igorpecovnik merged 1 commit intomainfrom
Conversation
github-actions
Bot
added
05
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (4)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Review rate limit: 0/1 reviews remaining, refill in 58 minutes and 59 seconds.Comment |
armbian/build PR #9683 retires the mesa-vpu extension — its
responsibilities (Mesa runtime + diagnostics, panthor-gpu overlay,
browser package selection) move into armbian-config's
module_desktops, called from rootfs-create at build time.
Once #9683 lands on main, every matrix slot that ships
ENABLE_EXTENSIONS=...mesa-vpu... will fail with:
ERR: Extension problem -- cant find extension 'mesa-vpu' anywhere
ERROR: Exiting with error 17 at lib/functions/general/extensions.sh:1
armbian/os run 25282829640 caught a preview of this on
rootfs-arm64-trixie-minimal. To unblock #9683's merge, drop every
mention of mesa-vpu from the matrix-emitting side:
* scripts/generate_targets.py: remove from the fast-HDMI
auto-attach list. v4l2loopback-dkms stays — it's a separate
extension, still owned by armbian/build. Comment now records
why mesa-vpu was retired so the next maintainer doesn't add
it back without reading the configng companion work.
* release-targets/targets-release-standard-support.manual:
strip ',mesa-vpu' from the four uefi-arm64 / uefi-x86 desktop
blocks (gnome / cinnamon, current / edge).
* release-targets/targets-extensions.map: strip ',mesa-vpu'
from the musepipro and bananapif3 entries (RISC-V K1, where
mesa-vpu never made sense anyway — that GPU is PowerVR, not
a Rockchip VPU). v4l2loopback-dkms stays per user scope.
* release-targets/targets-extensions.map.blacklist: the radxa-e54c
REMOVE_EXTENSIONS list shrinks to just v4l2loopback-dkms (mesa-vpu
isn't being added in the first place anymore). Comment header
+ examples updated.
* release-targets/README.md: doc references updated to match.
Behaviour after merge: the matrix output loses ',mesa-vpu' from
every slot's ENABLE_EXTENSIONS string. armbian/os pulls the new
release-targets/*.yaml on its next regen and the trixie-minimal
slot stops blowing up. v4l2loopback-dkms continues to attach where
it always did; nothing else moves.
igorpecovnik
force-pushed
the
release-targets-drop-mesa-vpu
branch
from
a39b356 to
97e5f65
Compare
1 participant
Summary
Strip every reference to the
mesa-vpuextension fromrelease-targets/. Companion to armbian/build#9683, which retires the extension itself.Why now
armbian/os run 25282829640, job 74125272015 —
rootfs-arm64-trixie-minimalfailed with:Once #9683 lands on
armbian/build's main, every fast-HDMI matrix slot still passingENABLE_EXTENSIONS=...mesa-vpu...will fail this way. This PR cleans up the matrix-emitting side so the merge doesn't break nightly.What changes
scripts/generate_targets.pyget_soc_extensionsmesa-vpufrom the fast-HDMI auto-attach list; keepv4l2loopback-dkmstargets-release-standard-support.manual,mesa-vpufrom explicitENABLE_EXTENSIONStargets-extensions.map,mesa-vpufrom the RISC-V K1 entries (where mesa-vpu never made sense — K1 is PowerVR, not a Rockchip VPU)targets-extensions.map.blacklistv4l2loopback-dkms(mesa-vpu isn't being added in the first place anymore)README.mdv4l2loopback-dkmsis left alone — it's a separate extension, still owned byarmbian/build. The user's scope was specifically mesa-vpu.A comment in
generate_targets.pyrecords why mesa-vpu was removed so the next maintainer reading the function doesn't re-add it without checking the configng companion work.Behaviour after merge
release-targets/*.yamlregenerates with no,mesa-vpuin anyENABLE_EXTENSIONSstring.armbian/osingests the new YAML on its next regen.rootfs-arm64-trixie-minimal(and every other slot that was breaking on this) goes green again on the next nightly.Test plan
Infrastructure: APT repositories update(or equivalent regen path); confirmrelease-targets/targets-release-*.yamlno longer containsmesa-vpu.armbian/osnightly and confirm fast-HDMI slots build (rootfs + image) with noExtension problemerrors.radxa-e54c: confirm v4l2loopback-dkms is still being removed for that board (the REMOVE list now lists only that one extension).