From: aba Date: Sat, 25 Jun 2005 12:04:55 +0000 (+0000) Subject: multiple fixes X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=commitdiff_plain;h=3210a6c768303c663ccfe933c328d6f9d4008819 multiple fixes git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@3432 313b444b-1b9f-4f58-a734-7bb04f332e8d --- diff --git a/common.ent b/common.ent index 4f6e9a0..9c35f4b 100644 --- a/common.ent +++ b/common.ent @@ -123,7 +123,7 @@ - + diff --git a/debian/changelog b/debian/changelog index 1582380..c82bebd 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,8 +2,16 @@ developers-reference (3.3.7) unstable; urgency=low * Andreas Barth: - adjust information about distributions with reality. - - -- Andreas Barth Wed, 8 Jun 2005 06:13:48 -0600 + - add note on alioth accounts. Thanks, Phillip Kern. Closes: #306630 + - correct manpage section of dpkg-scanpackages. Closes: #297069 + - fix RFC 2440 URL. Closes: #308105 + - add $arch@buildd information. Closes: #295483 + - link to keyring.d.o for key replacement. Thanks, Martin Michlmayr. + Closes: #298016 + - add information about Packages-arch-specific. Thanks, Frank Küster. + Closes: #302000 + + -- Andreas Barth Sat, 25 Jun 2005 06:04:20 -0600 developers-reference (3.3.6) unstable; urgency=low diff --git a/developers-reference.sgml b/developers-reference.sgml index 95f5bc3..a00841f 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -7,7 +7,7 @@ %dynamicdata; - + @@ -309,13 +309,12 @@ can update the Debian key ring by sending your key to the key server at &keyserver-host;.

If you need to add a completely new key or remove an old key, you need -to get the new key signed by another developer. After this, a mail -signed by another developer listing your account name, the keyids -of the old and of the new key and the reason should be send to -&email-debian-keyring;. If the old key is compromised or invalid, you +to get the new key signed by another developer. +If the old key is compromised or invalid, you also have to add the revocation certificate. If there is no real -reason for a new key, the Keyring Maintainers will only accept it if -it's more secure and connected to the old key. +reason for a new key, the Keyring Maintainers might reject the new key. +Details can be found at +.

The same key extraction routines discussed in apply. @@ -1543,6 +1542,10 @@ by Debian, facilitate contributions from external developers to projects started by Debian, and help projects whose goals are the promotion of Debian or its derivatives.

+All Debian developers automatically have an account on Alioth. +They can activate it by using the recover password facility. +External developers can request guest accounts on Alioth. +

For more information please visit . @@ -1954,7 +1957,7 @@ or priority for your package be changed from the old section or priority to the new one. Be sure to explain your reasoning.

For more information about override files, see and +name="dpkg-scanpackages" section="1"> and .

Note that the Section field describes both the section as @@ -2883,7 +2886,56 @@ different sub-flavors of Debian, which may or may not really be of general interest (for instance, a flavor of Debian built with gcc bounds checking). It will also enable Debian to recompile entire distributions quickly. - +

+The buildds admins of each arch can be contacted by the mail address +$arch@buildd.debian.org. + + When your package is not portable +

+Some packages still have issues with building and/or working on some +of the architectures supported by Debian, and cannot be ported at all, +or not with a reasonable amount of time. An example is a package that +is SVGA-specific (only i386), or uses other hardware-specific features +not supported on all architectures. +

+In order to prevent broken packages from being uploaded to the archive, and +wasting buildd time, you need to do a few things: +

+ + +

+First, make sure your package does fail to build on +architectures that it cannot support. +There are a few ways to achieve this. +The preferred way is to have a small testsuite during build time +that will test the functionality, and fail if it doesn't work. +This is a good idea anyway, +as this will prevent (some) broken uploads on all architectures, +and also will allow the package to build +as soon as the required functionality is available. +

+Additionally, if you believe the list of supported architectures is +pretty constant, you should change 'any' to a list of supported +architectures in debian/control. This way, the build will fail also, +and indicate this to a human reader without actually trying. + +

+In order to prevent autobuilders from needlessly trying to build your +package, it must be included in packages-arch-specific, a +list used by the wanna-build script. +The current version is available as +; +please see the top of the file for whom to contact for changes. + +

+Please note that it is insufficient to only add your package to +Packages-arch-specific +without making it fail to build on unsupported architectures: +A porter or any other person trying to build your package might +accidently upload it without noticing it doesn't work. +If in the past some binary packages were uploaded on unsupported architectures, +request there removal by filing a bug against +ftp.debian.org Non-Maintainer Uploads (NMUs)