ACK: [PATCH 0/9] LP: #1912803 -- autogenerate Nvidia rules/control
Marcelo Henrique Cerri
marcelo.cerri at canonical.com
Mon Jan 25 11:08:04 UTC 2021
It looks to me. That will help us a lot. Thanks for the work!!!
Acked-by: Marcelo Henrique Cerri <marcelo.cerri at canonical.com>
On Fri, Jan 22, 2021 at 04:23:01PM +0000, Andy Whitcroft wrote:
> Changing the version of an Nvidia package is pretty straight forward. We
> change the version in debian/dkms-versions in the *:linux (main) packages and
> this propogates to each derivative main kernel and from there into the
> dependant linux-restricted-modules* (lrm) package. However, when we wish to
> add a new 'series' such as 460 or 460-server things are much more complex.
> Firstly, we add a new dkms-versions entry for the series. We then add a pair
> of new stanzas to to the kernel packaging in the *:linux main packages (not
> overly onerous). Finally we must add new stanzas and package definitions to
> every single linux-restricted-modules* package individually (very very
> onerous). This email details some packaging improvements I am proposing for
> the main and lrm packages.
>
> For the main package we want to build signatures for all nvidia versions
> specified. Here I am removing the per-series rules and version lookup and
> replacing it with iterative make rules.
>
> For the lrm packages the intent is that the entire contents of lrm package is
> specified by the contents of two configurations; debian/dkms-versions which
> comes to lrm via its main package from the appropriate *:linux main package,
> and from debian/package.config which carries any per lrm configuration (mostly
> the architectures and flavours supported by that lrm package). The lrm rules
> and control are generated en-toto from these two configuration files at package
> clean time.
>
> With these in place we are able to add or remove (and transition) a version
> via modifications to the dkms-versions file in the *:linux main package.
> All other change propogates automatically into the generated rules.
>
> In order to handle sign-only[1] nvidia builds and to allow control over
> creation of appropriate transitional packags when deprecating series the
> dkms-versions format is extended for nvidia entries. Taking the current
> groovy:linux dkms-versions file as an example:
>
> zfs-linux 0.8.4-1ubuntu11.1
> nvidia-graphics-drivers-390 390.141-0ubuntu0.20.10.1
> nvidia-graphics-drivers-435 435.21-0ubuntu8 signonly
> nvidia-graphics-drivers-450 450.102.04-0ubuntu0.20.10.1 transition=nvidia-graphics-drivers-440
> nvidia-graphics-drivers-455 455.45.01-0ubuntu0.20.10.1 signonly
> nvidia-graphics-drivers-460 460.32.03-0ubuntu0.20.10.1 transition=nvidia-graphics-drivers-455 transition=nvidia-graphics-drivers-435
> nvidia-graphics-drivers-418-server 418.181.07-0ubuntu0.20.10.1
> nvidia-graphics-drivers-440-server 440.95.01-0ubuntu2 signonly
> nvidia-graphics-drivers-450-server 450.102.04-0ubuntu0.20.10.1 transition=nvidia-graphics-drivers-440-server
>
> The new directives are added in fields three onwards. Currently two
> directives are supported:
>
> - signonly -- which indicates that the main package should build and extract
> a signature from that nvidia series, but that lrm should not build the
> package, and
> - transition=<series package> -- which indicates that the older series should
> generate transitional packages pointing to this nvidia series.
>
> Additionally each lrm package will be configured via debian/package.config
> which contains (generally static) information such as the architectures and
> flavours for which we wish to generate packages. For example for
> focal:linux-hwe-5.8 we have:
>
> build generic amd64
> build lowlatency amd64
> option desktop
> option server
> transitional 440-oem-20.04 450-generic amd64
> transitional 450-oem-20.04 450-generic amd64
>
> This indicates we build on amd64 for generic and lowlatency flavours, we build
> both desktop (440, 450 etc) and server (450-server etc) series, and finally
> indicates that there are some addhoc transitionals needed to handle upgrades
> from the oem package.
>
> Currently three directives are supported:
>
> - build <flavour> <arch list> -- defines the architectures on which we should
> generate packages for this flavour.
> - option desktop|server -- defines whether this package generates desktop and
> server series respectivly.
> - transitional <from> <to> <arch list> -- defines the architectures on which
> transitional packages are needed for an adhoc transition.
>
> The changes for the main packages consist of two patches for each
> series; a change to debian/rules* to implement the dynamic rules, and a
> patch for debian/dkms-versions which adds the additional annotations. I
> include the rules change for the groovy main package as an example, the
> dkms-versions is as above (and will have to be regenerated at
> application time).
>
> The changes for the lrm packages are more complex as each lrm package must be
> configured indicating the flavours and architecures, and pulling out any local
> transitionals. I am including the patch kit[2] as applied to
> grooy:linux-restricted-modules package. This conversion has been scripted to
> simplify application. I am therefore including this as a sampler for review
> and and, but proposed to apply the lrm changes programatically.
>
> It should be noted that a pleasant outcome from this conversion is that once
> converted to this form all of the core LRM content is generated by a single
> common rules.gen script which can augmented and be updated via a cranky fix.
>
> -apw
>
> [1] signonly nvidia builds are used when transitioning from one series to
> another, but we might wish to drop back if testing fails. There we can build a
> signature in the old nvidia series, but not package or ship those in lrm.
>
> [2]
> Andy Whitcroft (9):
> UBUNTU: [Packaging] generate nvidia version mappings at clean time
> UBUNTU: [Packaging] generate nvidia version mappings at clean time -- add transitionals
> UBUNTU: [Packaging] generate nvidia version mappings at clean time -- handle Build-Depends
> UBUNTU: [Packaging] generate nvidia version mappings at clean time -- use Build-Depends-Arch
> UBUNTU: [Packaging] generate nvidia version mappings at clean time -- add signonly
> UBUNTU: [Packaging] generate nvidia version mappings at clean time -- handle +21.04.1
> UBUNTU: [Packaging] generate nvidia version mappings at clean time -- add options
> UBUNTU: [Packaging] generate nvidia version mappings at clean time -- handle old dkms-build API
> UBUNTU: [Packaging] generate nvidia version mappings at clean time -- add suppress support
>
> debian/control.common | 6 +-
> debian/control.d/meta-nvidia | 148 ---------------
> debian/control.d/migrate-nvidia-435 | 13 --
> debian/control.d/migrate-nvidia-440 | 13 --
> debian/control.d/nvidia | 227 -----------------------
> debian/control.d/transitionals-oem-20.04 | 13 --
> debian/dkms-versions | 5 +-
> debian/package.config | 4 +
> debian/rules | 194 +------------------
> debian/rules.in | 139 ++++++++++++++
> debian/scripts/gen-rules | 173 +++++++++++++++++
> debian/source/options | 3 +
> 12 files changed, 327 insertions(+), 611 deletions(-)
> delete mode 100644 debian/control.d/meta-nvidia
> delete mode 100644 debian/control.d/migrate-nvidia-435
> delete mode 100644 debian/control.d/migrate-nvidia-440
> delete mode 100644 debian/control.d/nvidia
> delete mode 100644 debian/control.d/transitionals-oem-20.04
> create mode 100644 debian/package.config
> create mode 100755 debian/rules.in
> create mode 100755 debian/scripts/gen-rules
>
> --
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
--
Regards,
Marcelo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20210125/07e1cc79/attachment-0001.sig>
More information about the kernel-team
mailing list