cranky: crl/handle -- include cycle name in lookup failures
When cranky is asked to work on a tree set that depends on changes not
represented in the effective kernel-series cycle an incomplete error
message is shown. Include the cycle name in the error as a hint to the
user that they should either fix the kernel-series@cycle or use the
correct cycle.
Add a handy script checking and summarizing the status of all CVE cards
in the `pending` column.
Setup
-----
1. Configure the UCT variable in shell source file.
Example: export UCT=$HOME/canonical/ubuntu-cve-tracker
2. Configure ~/.netrc for JIRA
Examples
--------
$ cve-check-pending -n 4 -l 3 # Display top 4 CVEs with 5 lines
CVE-2022-42721
CVE-2023-21106
- jammy_linux-oem-6.0: needed
CVE-2020-36516
- trusty/esm_linux: ignored (was needed ESM criteria)
CVE-2023-1382
- esm-infra/xenial_linux: ignored (was needed ESM criteria)
- bionic_linux: ignored (end of standard support, was needed)
- esm-infra/bionic_linux: needed
...and 34 more
...and 44 more CVE(s)
$ cve-check-pending -r # Display CVEs w/ the most needed/pending first
CVE-2023-1990
- esm-infra/xenial_linux: ignored (was needed ESM criteria)
- bionic_linux: ignored (end of standard support, was needed)
...and 114 more
CVE-2023-1611
- esm-infra/xenial_linux: ignored (was needed ESM criteria)
- bionic_linux: ignored (end of standard support, was needed)
...and 112 more
...and 45 more CVE(s)
---- Exceptions ----
CVE-2019-12381: current status is 'ignored'
CVE-2019-12382: current status is 'ignored'
^~~~ CVEs not in `active` or cannot be found in UCT will be
summarized here
Signed-off-by: Yuxuan Luo <email address hidden>
Acked-by: Cengiz Can <email address hidden>
Signed-off-by: Cengiz Can <email address hidden>
create-kernel-tasks: Work around spin 1 Launchpad bug
When looking up workflow trackers to check for exising ones there is a
difference between spin #1 and later ones. The reason why is somewhat
lost in history. While for later spins the library is called with a set
of all cycle tags, we pass an empty list for the initial spin.
This gets translated by the library into a search for all workflow tasks
which have a "kernel-release-tracking-bug-live" tag. Right now this
seems to return about 4000-5000 entries when done via the web page. The
API call however runs into a timeout and returns a Launchpad Oops.
Right now the simplest solution is to modify create-kernel-tasks to pass
in the cycle tag for spin #1 as well. Which also speeds up the runtime a
lot.
Signed-off-by: Stefan Bader <email address hidden>
Acked-by: Andy Whitcroft <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
create-kernel-tasks: Work around spin 1 Launchpad bug
When looking up workflow trackers to check for exising ones there is a
difference between spin #1 and later ones. The reason why is somewhat
lost in history. While for later spins the library is called with a set
of all cycle tags, we pass an empty list for the initial spin.
This gets translated by the library into a search for all workflow tasks
which have a "kernel-release-tracking-bug-live" tag. Right now this
seems to return about 4000-5000 entries when done via the web page. The
API call however runs into a timeout and returns a Launchpad Oops.
Right now the simplest solution is to modify create-kernel-tasks to pass
in the cycle tag for spin #1 as well. Which also speeds up the runtime a
lot.
Signed-off-by: Stefan Bader <email address hidden>
