From patchwork Fri Jan 22 16:23:01 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andy Whitcroft X-Patchwork-Id: 1430427 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4DMl1R3QpDz9sS8; Sat, 23 Jan 2021 03:23:23 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1l2zDR-0004Cp-LD; Fri, 22 Jan 2021 16:23:17 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1l2zDP-0004Cd-Qi for kernel-team@lists.ubuntu.com; Fri, 22 Jan 2021 16:23:15 +0000 Received: from mail-ed1-f72.google.com ([209.85.208.72]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1l2zDP-0006X3-J3 for kernel-team@lists.ubuntu.com; Fri, 22 Jan 2021 16:23:15 +0000 Received: by mail-ed1-f72.google.com with SMTP id w4so3169505edu.0 for ; Fri, 22 Jan 2021 08:23:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=q62imarPPibv3QncEIvdftMgxz4kopVr65Dqt0rqxfs=; b=MCBcuFgrNcs620iWBCuEVfxibUiMYDRbUveTarmDfjCCfkTimMORXQhYNyu12u0lri ww4n2kcwv7um/1m8VXm5L7Du/8LlqQEWiBIFoNpSPHp7K4m0I4abOAFb2g5fcPkyQjwL WzD+AcBDwyFu4wfnGpEQG9/WH5A1xKn6lcLzUsBPrL3EJ9Q8mMT149yp+8tR87LME7UC KvmdjEE+qzfSzX9NMY8latq290I/x5n9QIO4VlJQUatdLOXNdiApefL64UWu0FM/2SWv USmTuZwazAQtecvK8ESeziJ4/ZWlUm6Re/Rx4RUw4SPn1Pntj3s5nLx0rFGApa6dvbNx 53wA== X-Gm-Message-State: AOAM5327VUvJ3e3snbG47BsRjPyGSVHgecKWpRcSHIEGxg7Ui+iMTs2b kFD53A2Mm3SQIywgxqBKBE9SSOAHFKwVguSaqCnNovipU6HK+RAQiKhwu7CNASpaXplqpuvbXx6 WvSgABFezmb0fYeI4OxnXgX9VEfOV9Rfsj6lHFEaF0Q== X-Received: by 2002:a05:6402:4c1:: with SMTP id n1mr3852721edw.66.1611332594925; Fri, 22 Jan 2021 08:23:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJznCfY13Uh6JkNZra5FPrKVSHQN099S+MZJm2M315E1oktZCP5xFKy9E5OHwEnoqB4TEh7nJg== X-Received: by 2002:a05:6402:4c1:: with SMTP id n1mr3852699edw.66.1611332594610; Fri, 22 Jan 2021 08:23:14 -0800 (PST) Received: from localhost ([2001:470:6973:2:cb60:1396:20d7:1932]) by smtp.gmail.com with ESMTPSA id o13sm5610207edt.64.2021.01.22.08.23.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Jan 2021 08:23:13 -0800 (PST) From: Andy Whitcroft To: kernel-team@lists.ubuntu.com Subject: [PATCH 0/9] LP: #1912803 -- autogenerate Nvidia rules/control Date: Fri, 22 Jan 2021 16:23:01 +0000 Message-Id: <20210122162312.459010-1-apw@canonical.com> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andy Whitcroft Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" 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= -- 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 -- 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 -- 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 Acked-by: Kamal Mostafa Acked-by: Marcelo Henrique Cerri