| 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/uploading.html.
|
| 12 |
|
| 13 |
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 |
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 |
Use debdiff, interdiff etc. Use debdiff on the binary packages, too.
|
| 22 |
|
| 23 |
The distribution needs to be "testing-security".
|
| 24 |
|
| 25 |
If you append something to the version number currently in testing, use something
|
| 26 |
like "+lenny1" or ".0lenny1". A simple "lenny1" is not enough because of binNMUs
|
| 27 |
adding "+b1".
|
| 28 |
|
| 29 |
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 |
an overview, what packages have arrived in the queue.
|
| 59 |
|
| 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+lenny1_*.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 |
Troubleshooting
|
| 120 |
===============
|
| 121 |
|
| 122 |
- If something fails with releasing the built packages and you have to restart
|
| 123 |
dak, use a different DTSA version since they can just be used one.
|
| 124 |
- If you think the .dak files are just tmp files and you delete them, move the
|
| 125 |
files from the queue into /org/ftp.root/pub/OpenSecurityUploadQueue and
|
| 126 |
wait for the cronjob to push this into the queue again with new .dak files
|
| 127 |
(check file permissions).
|
| 128 |
|
| 129 |
22:37 < micah> sf: you got the key! now to rescue the princess
|
| 130 |
|
Parent Directory
| 
Revision Log