** Description changed: [ Impact ] Some platforms do not provide sufficiently discriminatory information in the modalias fields that ubuntu-drivers currently checks when selecting packages to install for a given platform. Enable packages in the archive to specify a specific MIDR value or DMI processor name as a selector, rather than exclusively relying on DMI family name (which is sometimes inconsistent between OEM flavors of platforms which should be treated the same way). [ Test Plan ] MIDR matching: 1. Create a package that defines a value for XB-Midr that matches for your DUT, then create a local apt archive with that package and add it to your sources.list. 2. Verify that `sudo ubuntu-drivers install` installs that package on your system 3. Repeat the test on a system with a different MIDR value and confirm it does not install there dmidecode matching: 1. Create a package that defines a value for XB-dmidecode that matches for your DUT, then create a local apt archive with that package and add it to your sources.list. 2. Verify that `sudo ubuntu-drivers install` installs that package on your system 3. Repeat the test on a system with a different DMI value and confirm it does not install there Regression test: 1. Copy your dmidecode and midr-enabled packages to a test archive on a machine that matches neither. 2. Run sudo ubuntu-drivers install and confirm that none of the new packages are installed We have also added functional tests to the ubuntu-drivers test suite for this behavior. [ Where problems could occur ] Since we have opted to implement this new functionality in a way that requires package maintainers to specify a completely novel field in their metadata rather than by changing the behavior of the existing modalias detection, there should be no risk of pre-existing packages unintentionally being installed on a user's device that weren't intended for that platform. If there is any mistake in our change to system_driver_packages, it could theoretically cause unexpected behavior. However, we've adjusted that loop in such a way that it should be totally silent for platforms for which the new identifiers are irrelevant, and verified via tests on several NVIDIA and non-NVIDIA devices. A spelling error from _is_open_prefered -> _is_open_preferred is corrected - while this function should have only been used internally and does not have any relevant usages in other packages via my most recent grep.app search, if some hypothetical user was for some reason depending on the old spelling, they may need to update it. Some additional prints are added during normal operation. While these should be harmless and obvious to manual users, if applications are dependent on rigid output formats, they may need adaptation. (however, they should only occur during non-root or otherwise already problematic usages, so I doubt this is a real concern.) + + [ FF / HWE Exception Request ] + + For Stonking: Our FFE exception request can be found here: + https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers- + common/+bug/2167853 + + For Resolute: Since these HW detection mechanisms should pose a low + regression risk and are necessary for the enablement of a few upcoming + platforms, I believe this upload is acceptable under the HWE exception.
** Description changed: [ Impact ] Some platforms do not provide sufficiently discriminatory information in the modalias fields that ubuntu-drivers currently checks when selecting packages to install for a given platform. Enable packages in the archive to specify a specific MIDR value or DMI processor name as a selector, rather than exclusively relying on DMI family name (which is sometimes inconsistent between OEM flavors of platforms which should be treated the same way). [ Test Plan ] MIDR matching: 1. Create a package that defines a value for XB-Midr that matches for your DUT, then create a local apt archive with that package and add it to your sources.list. 2. Verify that `sudo ubuntu-drivers install` installs that package on your system 3. Repeat the test on a system with a different MIDR value and confirm it does not install there dmidecode matching: 1. Create a package that defines a value for XB-dmidecode that matches for your DUT, then create a local apt archive with that package and add it to your sources.list. 2. Verify that `sudo ubuntu-drivers install` installs that package on your system 3. Repeat the test on a system with a different DMI value and confirm it does not install there Regression test: 1. Copy your dmidecode and midr-enabled packages to a test archive on a machine that matches neither. 2. Run sudo ubuntu-drivers install and confirm that none of the new packages are installed We have also added functional tests to the ubuntu-drivers test suite for this behavior. [ Where problems could occur ] Since we have opted to implement this new functionality in a way that requires package maintainers to specify a completely novel field in their metadata rather than by changing the behavior of the existing modalias detection, there should be no risk of pre-existing packages unintentionally being installed on a user's device that weren't intended for that platform. If there is any mistake in our change to system_driver_packages, it could theoretically cause unexpected behavior. However, we've adjusted that loop in such a way that it should be totally silent for platforms for which the new identifiers are irrelevant, and verified via tests on several NVIDIA and non-NVIDIA devices. A spelling error from _is_open_prefered -> _is_open_preferred is corrected - while this function should have only been used internally and does not have any relevant usages in other packages via my most recent grep.app search, if some hypothetical user was for some reason depending on the old spelling, they may need to update it. Some additional prints are added during normal operation. While these should be harmless and obvious to manual users, if applications are dependent on rigid output formats, they may need adaptation. (however, they should only occur during non-root or otherwise already problematic usages, so I doubt this is a real concern.) [ FF / HWE Exception Request ] For Stonking: Our FFE exception request can be found here: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers- common/+bug/2167853 - For Resolute: Since these HW detection mechanisms should pose a low + For Resolute: Since these new HW detection mechanisms should pose a low regression risk and are necessary for the enablement of a few upcoming platforms, I believe this upload is acceptable under the HWE exception. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2165071 Title: Unable to detect packages to install based on CPU type To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/2165071/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
