Merge ~rodrigo-zaiden/ubuntu-cve-tracker:kernel_abi_check_cycle into ubuntu-cve-tracker:master
Status: | Merged |
---|---|
Merged at revision: | 146049045bef57c3a927ca6eb28dd2320ef72313 |
Proposed branch: | ~rodrigo-zaiden/ubuntu-cve-tracker:kernel_abi_check_cycle |
Merge into: | ubuntu-cve-tracker:master |
Diff against target: |
80 lines (+32/-4) 2 files modified
scripts/kernel-abi-check (+8/-2) scripts/kernel_lib.py (+24/-2) |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Steve Beattie | Approve | ||
Review via email: mp+458365@code.launchpad.net |
Commit message
scripts/
with the new optional argument, '--check-cycle' the user can print out
the kernel sru cycle which that kernel that needs an USN is. It is
useful when we have multiple kernels needing USN and some could be a
lagging kernel that is in a different cycle, requiring a separated USN.
Description of the change
The usual output for the kernel-abi-check script is:
$ ./scripts/
USN needed: focal/linux-
USN needed: focal/linux-
USN needed: focal/linux-iot: 5.4.0-1028.29 (last USN: 5.4.0-1026.27)
USN needed: jammy/linux-
with the proposed change, if "--check-cycle" is used, we add the capability
to print out which cycle in the kernel sru we are, and will sound like:
$ ./scripts/
USN needed: focal/linux-
USN needed: focal/linux-
USN needed: focal/linux-iot: 5.4.0-1028.29 (last USN: 5.4.0-1026.27) - cycle: 2023.10.30-3
USN needed: jammy/linux-
As the idea here is to add an extra argument, there is no harm for the
current execution of the script.
The major benefit is to give the user who will be doing the USN to be able
to find kernel with same major version, in different cycles (probably with
different CVEs being fixed) that could end up in a same USN, which is
potentially wrong.
I've added a new commit that changes the definition of the method sru_cycle` from kernel-abi-check script to kernel_lib.py.
`get_kernel_
In kernel-abi-check we call it from the kernel_lib.
It was suggested by Steve and it makes sense that the method is defined
in a common place where other scripts may take advantage of the method if
needed. for this case for example, we have the script 'kernel-sru-check'
that is placed in UQT nowadays but will be moved to UCT that could be using
it.
I'm passing the lp api connection as a parameter because we already have
it in kernel-abi-check. Another idea would be to have it also defined in
kernel_lib.py only if needed. I think python would not initialize another
instance if the connection was already initialized in kernel-abi-check,
but as I'm not sure, I preferred to keep it simpler.