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	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