Message ID | 20210122162312.459010-1-apw@canonical.com |
---|---|
Headers | show |
Series | LP: #1912803 -- autogenerate Nvidia rules/control | expand |
ACK for all series. Acked-by: Kamal Mostafa <kamal@canonical.com> -Kamal 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@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team
It looks to me. That will help us a lot. Thanks for the work!!! Acked-by: Marcelo Henrique Cerri <marcelo.cerri@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@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team