| 1 |
A boilerplate for tracking the status of patches across Debian Kernel trees.
|
| 2 |
dannf> should anything go above this line?
|
| 3 |
dannf> should we use debian-style rfc822 for this for machine readability?
|
| 4 |
======================================================
|
| 5 |
Candidate: ##NEEDED## | CAN-XXXX-XXXX | N/A
|
| 6 |
Reference: CONFIRM:##URL##
|
| 7 |
Reference: MISC:##URL##
|
| 8 |
Description:
|
| 9 |
##NEEDED## dannf> can a single description work for the cve,
|
| 10 |
dannf> the changelog, and the DSA?
|
| 11 |
dannf> should this use debian/control style multiline?
|
| 12 |
dannf> should we have a short description?
|
| 13 |
|
| 14 |
Bug: [id, id, ...]
|
| 15 |
fixed-upstream: [version(, version)*]
|
| 16 |
2.6.13: (pending [(version)]|released [(version)]|N/A)[, backported][, patch-name-used.diff]
|
| 17 |
2.6.12: (pending [(version)]|released [(version)]|N/A)[, backported][, patch-name-used.diff]
|
| 18 |
2.6.8-sarge-security: (pending [(version)]|released [(version)]|N/A)[, backported][, patch-name-used.diff]
|
| 19 |
2.4.27-sarge-security: (pending [(version)]|released [(version)]|N/A)[, backported][, patch-name-used.diff]
|
| 20 |
woody kernels?
|
| 21 |
... one line for each currently maintained tree
|
| 22 |
|
| 23 |
dannf> what does backported mean? the patch didn't apply & needed munging,
|
| 24 |
dannf> or just that we used a patch intended for a newer tree, that may have
|
| 25 |
dannf> applied cleanly?
|