| 1 |
stef-guest |
5907 |
20:40 < micah> its good you are going through this, so we can note these |
| 2 |
|
|
various undocumented things that are necessary |
| 3 |
|
|
20:44 < micah> sf: its like a quest |
| 4 |
|
|
20:45 < sf> the secure-testing adventure |
| 5 |
|
|
|
| 6 |
|
|
|
| 7 |
|
|
Upload |
| 8 |
|
|
====== |
| 9 |
|
|
|
| 10 |
|
|
The upload can be done by any DD and is described in |
| 11 |
|
|
.../website/index.html. |
| 12 |
|
|
|
| 13 |
stef-guest |
5935 |
If the orig.tar.gz is already on security.debian.org (either stable-security |
| 14 |
|
|
or testing-security), then DON'T include it. Otherwise a bug in dak will |
| 15 |
|
|
prevent the buildds from building it. |
| 16 |
|
|
|
| 17 |
stef-guest |
5907 |
It is a good idea to check in the buildlog that all new patches |
| 18 |
|
|
actually get applied. Maybe you forgot to put them in patches/series |
| 19 |
|
|
or because of some bug dpatch ignored a patch. |
| 20 |
|
|
|
| 21 |
stef-guest |
6778 |
Use debdiff, interdiff etc. Use debdiff on the binary packages, too. |
| 22 |
stef-guest |
5907 |
|
| 23 |
|
|
The distribution needs to be "testing-security". |
| 24 |
|
|
|
| 25 |
stef-guest |
6778 |
If you append something to the version number currently in testing, use something |
| 26 |
|
|
like "+lenny1" or ".1lenny1". A simple "lenny1" is not enough because of binNMUs |
| 27 |
|
|
adding "+b1". |
| 28 |
|
|
|
| 29 |
stef-guest |
5907 |
dcut does not seem to work on security-master.debian.org, but someone |
| 30 |
|
|
in the sec_public group (micah, neilm, sf, jmm) can remove broken |
| 31 |
|
|
files from the upload queue when needed. |
| 32 |
|
|
|
| 33 |
|
|
|
| 34 |
|
|
|
| 35 |
|
|
Requirements |
| 36 |
|
|
============ |
| 37 |
|
|
|
| 38 |
|
|
Only DDs in the sec_public (and possibly the security?) group can |
| 39 |
|
|
accept the uploads (or even login on klecker). They also need to be |
| 40 |
|
|
member of the alias that gets the unembargoed build logs. See #88 on |
| 41 |
|
|
rt.d.o. |
| 42 |
|
|
|
| 43 |
|
|
|
| 44 |
|
|
|
| 45 |
|
|
Autobuilds |
| 46 |
|
|
========== |
| 47 |
|
|
|
| 48 |
|
|
When you have the buildlogs and the builds look ok, you have to sign |
| 49 |
|
|
the changes file embedded in the buildlog and send it to the buildd |
| 50 |
|
|
[1]. If you use your own script to do that: the Subject needs to be |
| 51 |
|
|
exactly as in the buildlog mail, but with a "Re: " prepended. |
| 52 |
|
|
|
| 53 |
|
|
A summary which buildlogs have arrived for which packages is at [2]. |
| 54 |
|
|
|
| 55 |
|
|
Some time after the buildd has received the signed .changes, it will |
| 56 |
|
|
upload the packages to klecker to |
| 57 |
|
|
/org/security.debian.org/queue/unembargoed/. "dak queue-report" gives |
| 58 |
thijs |
6422 |
an overview, what packages have arrived in the queue. |
| 59 |
stef-guest |
5907 |
|
| 60 |
|
|
If a buildd has problems: A list with the admins is at [3]. |
| 61 |
|
|
|
| 62 |
|
|
[1] http://wiki.debian.org/Buildd/BuildLogs |
| 63 |
|
|
[2] http://www.sfritsch.de/~stf/secure-testing-buildlogs.html |
| 64 |
|
|
[3] klecker:/org/security.debian.org/doc/buildd-admins.txt |
| 65 |
|
|
|
| 66 |
|
|
|
| 67 |
|
|
|
| 68 |
|
|
Releasing the packages |
| 69 |
|
|
====================== |
| 70 |
|
|
|
| 71 |
|
|
When all packages have arrived (or you want to release a subset |
| 72 |
|
|
because some buildds are broken), go to |
| 73 |
|
|
klecker:/org/security.debian.org/queue/unembargoed/ |
| 74 |
|
|
|
| 75 |
|
|
You can compare against a package in stable/updates with |
| 76 |
|
|
LANG=en_GB ~joey/bin/diffpackages -d stable clamav |
| 77 |
|
|
|
| 78 |
|
|
Otherwise do some debdiffing to ensure that the filelists and |
| 79 |
|
|
dependencies look correct. |
| 80 |
|
|
|
| 81 |
|
|
You can install the packages in the security archive with something |
| 82 |
|
|
like: |
| 83 |
|
|
|
| 84 |
|
|
dak new-security-install DTSA-36-1 mydns_1.1.0-7.1lenny1_*.changes |
| 85 |
|
|
|
| 86 |
|
|
DTSA-36-1 is an identifier that should be the name of the new DTSA. |
| 87 |
|
|
However, every identifier can be used only once with dak. So if you |
| 88 |
|
|
need a second run, use DTSA-36-1a or DTSA-36-2. |
| 89 |
|
|
|
| 90 |
|
|
"dak new-security-install" gives you an advisory template. This is not |
| 91 |
|
|
used for DTSAs. Ignore it. |
| 92 |
|
|
|
| 93 |
|
|
After the dak run, the new packages appear on security.debian.org and |
| 94 |
|
|
the mirrors are notified. You should get a mail that the packages are |
| 95 |
|
|
installed in testing-proposed-updates. |
| 96 |
|
|
|
| 97 |
|
|
|
| 98 |
|
|
|
| 99 |
|
|
Announcing |
| 100 |
|
|
========== |
| 101 |
|
|
|
| 102 |
|
|
If there has been a new stable release since the last DTSA, change the |
| 103 |
|
|
code names in all the scripts and templates ;-) |
| 104 |
|
|
|
| 105 |
|
|
How to create the announcement and how to update the tracker is also |
| 106 |
|
|
described in .../website/index.html |
| 107 |
|
|
|
| 108 |
|
|
After you sent the announcement to the announce list, you need to |
| 109 |
|
|
accept the mail on the moderator's page [4]. The sec_public people |
| 110 |
|
|
should have the password. |
| 111 |
|
|
|
| 112 |
|
|
Currently sf and luk (and possibly joeyh) can put the new announcements |
| 113 |
|
|
on the website (it's on alius.turmzimmer.net). These two should not |
| 114 |
|
|
forget to "chmod g+w" and "chgrp sectadm" the files. |
| 115 |
|
|
|
| 116 |
|
|
[4] http://lists.alioth.debian.org/mailman/admindb/secure-testing-announce |
| 117 |
|
|
|
| 118 |
|
|
|
| 119 |
|
|
|
| 120 |
|
|
22:37 < micah> sf: you got the key! now to rescue the princess |
| 121 |
|
|
|
Parent Directory
| 
Revision Log