release: Ship firmware from kmods repo on DVD
AcceptedPublic
Actions

Authored by cperciva on Sep 16 2025, 6:50 PM.

Details

Reviewers

bz
bapt

Group Reviewers

releng

Summary

The packages for X.Y-RELEASE are a snapshot of the quarterly branch
for stable/X, i.e. typically built on X.(Y-1)-RELEASE. (The case of
Y=0 is an exception for obvious reasons.) This works for most ports
but not for kernel modules, which may need to be built on the release
in question; this is why we have a separate "kmods" repository.

Make sure that we put the packages from the kmods repository onto the
mini-pkg-repo on the DVD rather than shipping unusable firmware.

(Note that this is not necessary for FreeBSD 15.0, but may be
necessary for 14.4.)

MFC after: 1 month
Sponsored by: https://www.patreon.com/cperciva

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 67090
Build 63973: arc lint + arc unit

Event Timeline

cperciva created this revision.Sep 16 2025, 6:50 PM

Herald added subscribers: jrtc27, imp. · View Herald TranscriptSep 16 2025, 6:50 PM

cperciva requested review of this revision.Sep 16 2025, 6:50 PM

Harbormaster completed remote builds in B67090: Diff 162185.Sep 16 2025, 6:50 PM

Rebase to latest main

Herald added a subscriber: ivy. · View Herald TranscriptWed, Jan 28, 4:24 AM

Harbormaster completed remote builds in B70177: Diff 170627.Wed, Jan 28, 4:24 AM

@bz @bapt I think you're more familiar with the whole "release-specific kmod builds" thing than anyone else -- can you take a look at this? I don't want to ship the 14.4-RELEASE dvd with wifi kmods from 14.3.

I do not understand our package repositories and what goes into the releases anymore.
There's two branches in ports: main and quarterly; quarterly is almost certainly always outdated but I do not know how the "kmod" ports are dealt with in terms for that.
Is there one-repo-fits both main and quarterly or are they separate and we are building the full matrix?

Apart from file changes for wifi firmware it doesn't matter anymore as none of that is .ko; it's all plain firmware files, so they would at least still load though one occasionally missing the latest revisions.
14.4 has not seen wireless driver updates (yet) and given I didn't get any feedback on my LinuxKPI etc MFCs despite asking for it I have no intentions to change the status-quo for 14 anymore before 14.4 unless there's a missing bug fix.

In D52581#1255798, @bz wrote:

I do not understand our package repositories and what goes into the releases anymore.
There's two branches in ports: main and quarterly; quarterly is almost certainly always outdated but I do not know how the "kmod" ports are dealt with in terms for that.
Is there one-repo-fits both main and quarterly or are they separate and we are building the full matrix?

If this commit reaches releng/14.4, at that point it would point to release_4 and kmods_release_4, which would be copies of quarterly and kmods_quarterly_4 made at the appropriate time. So we're talking about packages built from the quarterly (in this case 2026Q1) branch of the ports tree; the difference between the "kmod" repo and the non-kmod repo is that the kmod repo only has kmod packages and is built with a newer src tree.

Apart from file changes for wifi firmware it doesn't matter anymore as none of that is .ko; it's all plain firmware files, so they would at least still load though one occasionally missing the latest revisions.
14.4 has not seen wireless driver updates (yet) and given I didn't get any feedback on my LinuxKPI etc MFCs despite asking for it I have no intentions to change the status-quo for 14 anymore before 14.4 unless there's a missing bug fix.

Ok, maybe it doesn't matter for 14.4. Is it possible that in the future we'll need wifi packages built on the most recent minor release? Or if, as you say, it's all plain firmware would wifi firmware packages built on say 15.0 work just fine on 15.1?

We definitely need built-on-the-right-minor-release packages for *graphics* but I don't think we're currently shipping any of those packages on the DVD so maybe this change won't be relevant until/unless that changes.

In D52581#1255918, @cperciva wrote:

In D52581#1255798, @bz wrote:

I do not understand our package repositories and what goes into the releases anymore.
There's two branches in ports: main and quarterly; quarterly is almost certainly always outdated but I do not know how the "kmod" ports are dealt with in terms for that.
Is there one-repo-fits both main and quarterly or are they separate and we are building the full matrix?

If this commit reaches releng/14.4, at that point it would point to release_4 and kmods_release_4, which would be copies of quarterly and kmods_quarterly_4 made at the appropriate time. So we're talking about packages built from the quarterly (in this case 2026Q1) branch of the ports tree; the difference between the "kmod" repo and the non-kmod repo is that the kmod repo only has kmod packages and is built with a newer src tree.

Too many repos for me. But so be it. So if your change is taking packages for the DVD for firmware ("kmod") from kmods_release_4 resp. kmods_quarterly_4 then that sounds good to me.
From most of the shell bits I get that looks good as well. I assume the release-dvd.conf will need to change repos then in the release branch but that's a re@ task?

Apart from file changes for wifi firmware it doesn't matter anymore as none of that is .ko; it's all plain firmware files, so they would at least still load though one occasionally missing the latest revisions.
14.4 has not seen wireless driver updates (yet) and given I didn't get any feedback on my LinuxKPI etc MFCs despite asking for it I have no intentions to change the status-quo for 14 anymore before 14.4 unless there's a missing bug fix.

Ok, maybe it doesn't matter for 14.4. Is it possible that in the future we'll need wifi packages built on the most recent minor release? Or if, as you say, it's all plain firmware would wifi firmware packages built on say 15.0 work just fine on 15.1?

Modulo firmware version changes. So it's good to have the right ones. In theory that package no longer is a "kmod" but cleaning that up I will wait until 13.5 is EoL.

We definitely need built-on-the-right-minor-release packages for *graphics* but I don't think we're currently shipping any of those packages on the DVD so maybe this change won't be relevant until/unless that changes.

I have firm plans to make the gpu-firmware pain go away once 13.5 is EoL if no one else will beat me to it. As then they can be shipped as plain firmware files as well and all the .ko version matching will vanish over night.

This revision is now accepted and ready to land.Wed, Jan 28, 10:14 PM

this is very simple how the kmods are built:
kmods are built for every arches, every release (and stable)
FreeBSD:X:arch/kmods_quarterly are the kmods from the quarterly ports branch for the X branch (X being stable or main) of the source tree (using the weekly pkgbase repo which are always published in a predictable manner)
FreeBSD:X:arch/kmods_latest are the kmods from the main ports branch for the X branch (X being stable or main) of the source tree (using the weekly pkgbase repo)
FreeBSD:X:arch/kmods_quarterly_Y are the kmods from the quarterly ports branch for the X.Y releng branch of the source tree (using the releng pkgbase repo)
FreeBSD:X:arch/kmods_latest_Y are the kmods from the main ports branch for the X.Y releng branch of the source tree (using the releng pkgbase repo)