I am generally +1 with SRUing this, BUT this is a special in a few ways: 1/ In order to land this in Focal, we first need to apply it to Impish and Hirsute (according to SRU process), as ddstreet mentioned.
2/ We are already post Feature Freeze for Impish and this is adding new functionality IMO (in contrast to fixing a bug). So I wonder if we'd need a Feature Freeze exception – that should be clarified with the release team. 3/ The debdiff looks good to me at first glance, BUT: We need to also inject the "gboolean ignore_carrier" field into the "net_definition" struct before the new offload fields (i.e. parse.h change from this commit https://github.com/canonical/netplan/commit/d4884cfd40e1e33540b274371c3272df6595d22c). Otherwise this patch will break ABI compatibility once the next upstream release would be SRUed... -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1771740 Title: Expose link offload options Status in netplan: Fix Committed Status in netplan.io package in Ubuntu: New Status in netplan.io source package in Focal: New Status in netplan.io source package in Hirsute: New Status in netplan.io source package in Impish: New Bug description: [Impact] * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. [Test Plan] * detailed instructions how to reproduce the bug * these should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. * if other testing is appropriate to perform before landing this update, this should also be described here. [Where problems could occur] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must '''never''' be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance [Original Description] https://www.freedesktop.org/software/systemd/man/systemd.link.html has a number of [Link] options which I need to use for a flaky network card (TCPSegmentationOffload, TCP6SegmentationOffload, GenericSegmentationOffload, GenericReceiveOffload, LargeReceiveOffload) which are not exposed via netplan. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1771740/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : [email protected] Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
