http://packages.debian.org/sid/developers-reference – - (due to lack of corresponding source code). The “magic” for a recompilation-only NMU is triggered by using a suffix appended to the package version number, following the form bnumber. For instance, if the latest version you are recompiling against was version 2.9-3, your binary-only NMU should carry a version of 2.9-3+b1. If the latest version was 3.4+b1 (i.e, a native package with a previous recompilation NMU), your binary-only NMU should have a version number of 3.4+b2. ^[4] Similar to initial porter uploads, the correct way of invoking dpkg-buildpackage is dpkg-buildpackage -B to only build the architecture-dependent parts of the package. 5.10.2.2. When to do a source NMU if you are a porter Porters doing a source NMU generally follow the guidelines found in Section 5.11, Non-Maintainer Uploads (NMUs) , just like non-porters. However, it is expected that the wait cycle for a porter’s source NMU is smaller than for a non-porter, since porters have to cope with a large quantity of packages. Again, the situation varies depending on the distribution they are uploading to. It also varies whether the architecture is a candidate for inclusion into the next stable release; the release managers decide and announce which architectures are candidates. If you are a porter doing an NMU for unstable, the above guidelines for porting should be followed, with two variations. Firstly, the acceptable waiting period — the time between when the bug is submitted to the BTS and when it is OK to do an NMU — is seven days for porters working on the unstable distribution. This period can be shortened if the problem is critical and imposes hardship on the porting effort, at the discretion of the porter group. (Remember, none of this is Policy, just mutually agreed upon guidelines.) For uploads to stable or testing , please coordinate with the appropriate release team first. Secondly, porters doing source NMUs should make sure that the bug they submit to the BTS should be of severity serious or greater. This ensures that a single source package can be used to compile every supported Debian architecture by release time. It is very important that we have one version of the binary and source package for all architectures in order to comply with many licenses. Porters should try to avoid patches which simply kludge around bugs in the current version of the compile environment, kernel, or libc. Sometimes such kludges can’t be helped. If you have to kludge around Compiler bugs and the like, make sure you #ifdef your work properly; also, document your kludge so that people know to remove it once the external problems have been fixed. Porters may also have an unofficial location where they can put the results of their work during the waiting period. This helps others running the port have the benefit of the porter’s work, even during the waiting period. Of course, such locations have no official blessing or status, so buyer beware. 5.10.3. Porting infrastructure and automation There is infrastructure and several tools to help automate package porting. This section contains a brief overview of this automation and porting to these tools; see the package documentation or references for full information. 5.10.3.1. Mailing lists and web pages Web pages containing the status of each port can be found at http://www.debian.org/ports/. Each port of Debian has a mailing list. The list of porting mailing lists can be found at http://lists.debian.org/ ports.html . These lists are used to coordinate porters, and to connect the users of a given port with the porters. 5.10.3.2. Porter tools Descriptions of several porting tools can be found in Section A.7, Porting tools .5.10.3.3. wanna-build The wanna-build system is used as a distributed, client-server build distribution system. It is usually used in conjunction with build daemons running the buildd program. Build daemons are “slave” hosts which contact the central wanna-build system to receive a list of packages that need to be built. wanna-build is not yet available as a package; however, all Debian porting efforts are using it for automated package building. The tool used to do the actual package builds, sbuild is available as a package, see its description in Section A.4.4, sbuild . Please note that the packaged version is not the same as the one used on build daemons, but it is close enough toreproduce problems. Most of the data produced by wanna-build which is generally useful to porters is available on the web at http:// buildd.debian.org/. This data includes nightly updated statistics, queueing information and logs for build attempts. We are quite proud of this system, since it has so many possible uses. Independent development groups can use the system for different sub-flavors of Debian, which may
Duration : 0:7:32
