cranky: fix -- update update-dkms-versions to support --remote-branch
Now that we have a flat kernel-versions repository it makes sense to use
branches in the main archive to represent things like the "next" version
of packages. Update the master version of update-dkms-versions applied
by cranky-fix to support --remote-branch
Signed-off-by: Andy Whitcroft <email address hidden>
cranky: pull-sources: add wrapper around pull-source
cranky pull-source works with a single package, whereas most other cranky
commands work with a handle. Most of the time, crankers want to download
all the packages for a given kernel.
Also, cranky pull-source will download the latest version it finds in the
archive, but only if packages are in the archive. If they are in a PPA, the
version needs go be given and they are not the same for every package.
Instead of looking for versions in a specific pocket, cranky-pull-sources
look at the changelog of checked out trees and tries to download the
previos version. This covers the use case where crankers will review
packages after preparing and building packages (similarly reviewers will
have checked out and reviewed the prepared tree).
This will fail the case where a tree had to prepared again due to a build
failure or the package to be reviewed against is not the previous version
as in the changelog. Still, this should work for the most common cases.
cranky: pull-sources: add wrapper around pull-source
cranky pull-source works with a single package, whereas most other cranky
commands work with a handle. Most of the time, crankers want to download
all the packages for a given kernel.
Also, cranky pull-source will download the latest version it finds in the
archive, but only if packages are in the archive. If they are in a PPA, the
version needs go be given and they are not the same for every package.
Instead of looking for versions in a specific pocket, cranky-pull-sources
look at the changelog of checked out trees and tries to download the
previos version. This covers the use case where crankers will review
packages after preparing and building packages (similarly reviewers will
have checked out and reviewed the prepared tree).
This will fail the case where a tree had to prepared again due to a build
failure or the package to be reviewed against is not the previous version
as in the changelog. Still, this should work for the most common cases.
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Changes to update the cycle dates in kernel.ubuntu.com to include the security cycles schedule. This required some refactoring to make it easier to expand the code and the html tables.
TODO:
* fix text output for the mailing-list
* add a flag to suppress security cycles
gen-sru-announce: merge prep and test weeks in html output
The "prep week" and "verification and test weeks" timelines doesn't make
much sense anymore, given that we have introduced the security cycles
and there isn't a clear line separating those stages in the cycle. Merge
these two phases into a single "prep and test weeks".
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
Using a tuple to generate the SRU cycle dates and pass it to several
functions that consume it makes it hard to read and maintain the code.
Change it to a dictionary so it's easier to expand the relevant dates.
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
