chiark / gitweb /
lwn
[developers-reference.git] / developers-reference.sgml
index 95f5bc35f33b2e9689aa592fdbde4b46a412ac26..37b29c8c2242bcabcb2fd880dff442e4474d23cf 100644 (file)
@@ -7,7 +7,7 @@
   <!ENTITY % dynamicdata  SYSTEM "dynamic.ent" > %dynamicdata;
 
   <!-- CVS revision of this document -->
-  <!ENTITY cvs-rev "$Revision: 1.264 $">
+  <!ENTITY cvs-rev "$Revision: 1.266 $">
 
   <!-- if you are translating this document, please notate the CVS
        revision of the original developer's reference in cvs-en-rev -->
@@ -309,13 +309,12 @@ can update the Debian key ring by sending your key to the key server at
 <tt>&keyserver-host;</tt>.
        <p>
 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 
+<url id="http://keyring.debian.org/replacing_keys.html">.
        <p>
 The same key extraction routines discussed in <ref id="registering">
 apply. 
@@ -1543,8 +1542,23 @@ 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.
        <p>
+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.
+        <p>
 For more information please visit <url id="&url-alioth;">.
 
+    <sect id="developer-misc">Goodies for Developers
+        <p>
+     <sect1 id="lwn">LWN Subscriptions
+        <p>
+Since October of 2002, HP has sponsored a subscription to LWN for all 
+interested Debian developers.
+
+Details on how to get access to this benefit are in
+<url id="http://lists.debian.org/debian-devel-announce/2002/10/msg00018.html">.
+
+
 
    <chapt id="pkgs">Managing Packages
        <p>
@@ -1954,7 +1968,7 @@ or priority for your package be changed from the old section or
 priority to the new one.  Be sure to explain your reasoning.
        <p>
 For more information about <em>override files</em>, see <manref
-name="dpkg-scanpackages" section="8"> and
+name="dpkg-scanpackages" section="1"> and
 <url id="&url-bts-devel;#maintincorrect">.
        <p>
 Note that the <tt>Section</tt> field describes both the section as
@@ -2883,7 +2897,56 @@ different sub-flavors of Debian, which may or may not really be of
 general interest (for instance, a flavor of Debian built with <prgn>gcc</prgn>
 bounds checking).  It will also enable Debian to recompile entire
 distributions quickly.
-          </sect2>
+          <p>
+The buildds admins of each arch can be contacted by the mail address
+$arch@buildd.debian.org.
+
+       <sect1 id="packages-arch-specific">When your package is <em>not</em> portable
+       <p>
+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.
+       <p>
+In order to prevent broken packages from being uploaded to the archive, and
+wasting buildd time, you need to do a few things:
+       <p>
+      <list>
+      <item>
+       <p>
+First, make sure your package <em>does</em> 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.
+       <p>
+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.
+      <item>
+       <p>
+In order to prevent autobuilders from needlessly trying to build your
+package, it must be included in <file>packages-arch-specific</file>, a
+list used by the <prgn>wanna-build</prgn> script.
+The current version is available as
+<url id="http://cvs.debian.org/srcdep/Packages-arch-specific?rev=HEAD&cvsroot=dak&content-type=text/vnd.viewcvs-markup">;
+please see the top of the file for whom to contact for changes.
+      </list>
+       <p>
+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
+<package>ftp.debian.org</package>
 
 
     <sect id="nmu">Non-Maintainer Uploads (NMUs)