Contents of /doc/how-to-DTSA

20:40 < micah> its good you are going through this, so we can note these 
               various undocumented things that are necessary
20:44 < micah> sf: its like a quest
20:45 < sf> the secure-testing adventure


Upload
======

The upload can be done by any DD and is described in
.../website/index.html.

It is a good idea to check in the buildlog that all new patches
actually get applied. Maybe you forgot to put them in patches/series
or because of some bug dpatch ignored a patch.

Use debdiff, interdiff etc.

The distribution needs to be "testing-security".

dcut does not seem to work on security-master.debian.org, but someone
in the sec_public group (micah, neilm, sf, jmm) can remove broken
files from the upload queue when needed.


Requirements
============

Only DDs in the sec_public (and possibly the security?) group can
accept the uploads (or even login on klecker). They also need to be
member of the alias that gets the unembargoed build logs. See #88 on
rt.d.o.


Autobuilds
==========

There seems to be a bug in dak: If the orig.tar.gz is already in
stable-security, the orig.tar.gz is not symlinked into the
buildd/lenny  directory and the buildds cannot download the source.
Workaround: Ask aj to create the symlink manually

When you have the buildlogs and the builds look ok, you have to sign
the changes file embedded in the buildlog and send it to the buildd
[1]. If you use your own script to do that: the Subject needs to be
exactly as in the buildlog mail, but with a "Re: " prepended.

A summary which buildlogs have arrived for which packages is at [2].

Some time after the buildd has received the signed .changes, it will
upload the packages to klecker to
/org/security.debian.org/queue/unembargoed/. "dak queue-report" gives
an overview, what packges have arrived in the queue.

If a buildd has problems: A list with the admins is at [3].

[1] http://wiki.debian.org/Buildd/BuildLogs
[2] http://www.sfritsch.de/~stf/secure-testing-buildlogs.html
[3] klecker:/org/security.debian.org/doc/buildd-admins.txt


Releasing the packages
======================

When all packages have arrived (or you want to release a subset
because some buildds are broken), go to
klecker:/org/security.debian.org/queue/unembargoed/

You can compare against a package in stable/updates with
LANG=en_GB ~joey/bin/diffpackages -d stable clamav

Otherwise do some debdiffing to ensure that the filelists and
dependencies look correct.

You can install the packages in the security archive with something
like:

dak new-security-install DTSA-36-1 mydns_1.1.0-7.1lenny1_*.changes

DTSA-36-1 is an identifier that should be the name of the new DTSA.
However, every identifier can be used only once with dak. So if you
need a second run, use DTSA-36-1a or DTSA-36-2.

"dak new-security-install" gives you an advisory template. This is not
used for DTSAs. Ignore it.

After the dak run, the new packages appear on security.debian.org and
the mirrors are notified. You should get a mail that the packages are
installed in testing-proposed-updates.


Announcing
==========

If there has been a new stable release since the last DTSA, change the
code names in all the scripts and templates ;-)

How to create the announcement and how to update the tracker is also
described in .../website/index.html

After you sent the announcement to the announce list, you need to
accept the mail on the moderator's page [4]. The sec_public people
should have the password.

Currently sf and luk (and possibly joeyh) can put the new announcements
on the website (it's on alius.turmzimmer.net). These two should not
forget to "chmod g+w" and "chgrp sectadm" the files.

[4] http://lists.alioth.debian.org/mailman/admindb/secure-testing-announce


22:37 < micah> sf: you got the key! now to rescue the princess

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