Posts Tagged ‘debian’
March 9th, 2010 | 
Author: 
http://packages.debian.org/sid/developers-reference – - Bcc: pts-news@qa.debian.org Subject: Galeon 2.0 backported for woody X-PTS-Package: galeon Hello gnomers! I’m glad to announce that galeon has been backported for woody. You’ll find everything here: … Think twice before adding a news item to the PTS because you won’t be able to remove it later and you won’t be able to edit it either. The only thing that you can do is send a second news item that will deprecate the information contained in the previous one. 4.11. Developer’s packages overview A QA (quality assurance) web portal is available at http:// qa.debian.org/developer.php which displays a table listing all the packages of a single developer (including those where theparty is listed as a co-maintainer). The table gives a good summary about the developer’s packages: number of bugs by severity, list of available versions in each distribution, testing status and much more including links to any other useful information. It is a good idea to look up your own data regularly so that you don’t forget any open bugs, and so that you don’t forget which packages are your responsibility. 4.12. Debian’s GForge installation: Alioth Alioth is a Debian service based on a slightly modified version of the GForge software (which evolved from SourceForge). This software offers developers access to easy-to-use tools such as bug trackers, patch manager, project/task managers, file hosting services, mailing lists, CVS repositories etc. All these tools are managed via a web interface. It is intended to provide facilities to free software projects backed or led 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. It’s heavily used by many Debian teams and provides hosting for all sorts of VCS repositories. 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 the following links: * http://wiki.debian.org/Alioth * http://wiki.debian.org/Alioth/FAQ * http://wiki.debian.org/ Alioth/PackagingProject * http://alioth.debian.org/ 4.13. Goodies for Developers 4.13.1. LWN Subscriptions 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 http://lists.debian.org/ debian-devel-announce/ 2002/10/msg00018.html. Chapter 5. Managing Packages This chapter contains information related to creating, uploading, maintaining, and porting packages. 5.1. New packages If you want to create a new package for the Debian distribution, you should first check the Work-Needing and Prospective Packages (WNPP) list. Checking the WNPP list ensures that no one is already working on packaging that software, and that effort isnot duplicated. Read the WNPP web pages for more information. Assuming no one else is already working on your prospective package, you must then submit a bug report (Section 7.1, Bug reporting ) against the pseudo-package wnpp describing your plan to create a new package, including, but not limiting yourself to, a description of the package, the license of the prospective package, and the current URL where it can be downloaded from. You should set the subject of the bug to ITP: foo — short description, substituting the name of the new package for foo. The severity of the bug report must be set to wishlist. Please send a copy to [debian-devel@ lists.debian.org] by using the X-Debbugs-CC header (don’t use CC:, because that way the message’s subject won’t indicate the bug number). If you are packaging so many new packages (]10) that notifying the mailing list in seperate messages is too disruptive, do send a summary after filing the bugs to the debian-devel list instead. This will inform the other developers about upcoming packages and will allow a review of your description and package name. Please include a Closes: bug#nnnnn entry in the changelog of the new package in order for the bug report to be automatically closed once the new package is installed in the archive (see Section 5.8.4, When bugs are closed by new uploads ). When closing security bugs include CVE numbers as well as the Closes: #nnnnn. This is useful for the security team to track vulnerabilities. If an upload is made to fix the bug before the advisory ID is known, it is encouraged to modify the historical changelog entry with the next upload. Even in this case, please include all available pointers to background information in the original changelog entry. There are a number of reasons why we ask maintainers to announce their intentions: * It helps the (potentially new) maintainer to tap into the experience of people
Duration : 0:7:45
Posted in 
Tags: 
http://packages.debian.org/sid/developers-reference – - that they decide to help finish a major upgrade (like a new perl version which requires recompilation of all the binary modules) . The rules for non-maintainer uploads differ during the parties because the announcement of the party is considered prior notice for NMU. If you have packages that may be affected by the party (because they have release critical bugs for example) , you should send an update to each of the corresponding bug to explain their current status and what you expect from the party. If you don’t want an NMU, or if you’re only interested in a patch, or if you will deal yourself with the bug, please explain that in the BTS. People participating in the party have special rules for NMU, they can NMU without prior notice if they upload their NMU to DELAYED/3-day at least. All other NMU rules apply as usually; they should send the patch of the NMU to the BTS (to one of the open bugs fixed by the NMU, or to a new bug, tagged fixed). They should also respect any particular wishes of the maintainer. If you don’t feel confident about doing an NMU, just send a patch to the BTS. It’s far better than a broken NMU. 7.3.**Contacting other maintainers During your lifetime within Debian, you will have to contact other maintainers for various reasons. You may want to discuss a new way of cooperating between a set of related packages, or you may simply remind someone that a new upstream version is available and that you need it.Looking up the email address of the maintainer for the package can be distracting. Fortunately, there is a simple email alias, [package]@packages.debian.org, which provides a way to email the maintainer, whatever their individual email address (or addresses) may be. Replace [package] with the name of a source or a binary package. You may also be interested in contacting the persons who are subscribed to a given source package via Section* *4.10, ***The Package Tracking System* ** . You can do so by using the [package] @packages.qa.debian.org email address. 7.4.**Dealing with inactive and/or unreachable maintainers If you notice that a package is lacking maintenance, you should make sure that the maintainer is active and will continue to work on their packages. It is possible that they are not active any more, but haven’t registered out of the system, so to speak. On the other hand, it is also possible that they just need a reminder. There is a simple system (the MIA database) in which information about maintainers who are deemed Missing In Action is recorded. When a member of the QA group contacts an inactive maintainer or finds more information about one, this is recorded in the MIA database. This system is available in /org/ qa.debian.org/mia on the host qa.debian.org , and can be queried with the mia-query tool. Use mia-query –help to see how to query the database. If you find that no information has been recorded about an inactive maintainer yet, or that you can add more information, you should generally proceed as follows. The first step is to politely contact the maintainer, and wait a reasonable time for a response. It is quite hard to define reasonable time, but it is important to take into account that real life is sometimes very hectic. One way to handle this would be to send a reminder after two weeks. If the maintainer doesn’t reply within four weeks (a month), one can assume that a response will probably not happen. If that happens, you should investigate further, and try to gather as much useful information about the maintainer in question as possible. This includes: * The echelon information available through the developers’ LDAP database, which indicates when the developer last posted to a Debian mailing list. (This includes mails about uploads distributed via the [ debian-devel-changes@ lists.debian.org] list.) Also, remember to check whether the maintainer is marked as on vacation in the database. * The number of packages this maintainer is responsible for, and the condition of those packages. In particular, are there any RC bugs that have been open for ages? Furthermore, how many bugs are there in general? Another important piece of information is whether the packages have been NMUed, and if so, by whom. * Is there any activity of the maintainer outside of Debian? For example, they might have posted something recently to non-Debian mailing lists or news groups. A bit of a problem are packages which were sponsored *** the maintainer is not an official Debian developer. The echelon information is not available for sponsored people, for example, so you need to find and contact the Debian developer who has actually uploaded the package. Given that they signed the package, they’re responsible for the upload anyhow, and are likely to know what happened
Duration : 0:7:8
http://packages.debian.org/sid/developers-reference – - mirrors and get used to using them, which allows Debian to better spread its bandwidth requirements over several servers and networks, and basically makes users avoid hammering on one primary location. Note that the first tier of mirrors is as up-to-date as it can be since they update when triggered from the internal sites (we call this push mirroring). All the information on Debian mirrors, including a list of the available public FTP/ HTTP servers, can be found at http:// www.debian.org/mirror/ . This useful page also includes information and tools which can be helpful if you are interested in setting up your own mirror, either for internal or public access. Note that mirrors are generally run by third-parties who are interested in helping Debian. As such, developers generally do not have accounts on these machines. 4.8. The Incoming system The Incoming system is responsible for collecting updated packages and installing them in the Debian archive. It consists of a set of directories and scripts that are installed on ftp-master.debian.org. Packages are uploaded by all the maintainers into a directory called UploadQueue. This directory is scanned every few minutes by a daemon called queued, *.command-files are executed, and remaining and correctly signed *.changes-files are moved together with their corresponding files to the unchecked directory. This directory is not visible for most Developers, as ftp-master is restricted; it is scanned every 15 minutes by the katie script, which verifies the integrity of the uploaded packages and their cryptographic signatures. If the package is considered ready to be installed, it is moved into the accepted directory. If this is the first upload of the package (or it has new binary packages), it is moved to the new directory, where it waits for approval by the ftpmasters. If the package contains files to be installed by hand it is moved to the byhand directory, where it waits for manual installation by the ftpmasters. Otherwise, if any error has been detected, the package is refused and is moved to the reject directory. Once the package is accepted, the system sends a confirmationmail to the maintainer and closes all the bugs marked as fixed by the upload, and the auto-builders may start recompiling it. The package is now publicly accessible at http:// incoming.debian.org/ until it is really installed in the Debian archive. This happens only once a day (and is also called the `dinstall run’ for historical reasons); the package is then removed from incoming and installed in the pool along with all the other packages. Once all the other updates (generating new Packages and Sources index files for example) have been made, a special script is called to ask all the primary mirrors to update themselves. The archive maintenance software will also send the OpenPGP/ GnuPG signed .changes file that you uploaded to the appropriate mailing lists. If a package is released with the Distribution: set to stable, the announcement is sent to [ debian-changes@lists.debian.org]. If a package is released with Distribution: set to unstable or experimental, the announcement will be posted to [debian-devel-changes@ lists.debian.org] instead. Though ftp-master is restricted, a copy of the installation is available to all developers on merkel.debian.org. 4.9. Package information 4.9.1. On the web Each package has several dedicated web pages. http:// packages.debian.org/package-name displays each version of the package available in the various distributions. Each version links to a page which provides information, including the package description, the dependencies, and package downloadlinks. The bug tracking system tracks bugs for each package. You can view the bugs of a given package at the URL http: // bugs.debian.org/package-name. 4.9.2. The dak ls utility dak ls is part of the dak suite of tools, listing available package versions for all known distributions and architectures. The dak tool is available on ftp-master.debian.org , and on the mirror on merkel.debian.org. It uses a single argument corresponding to a package name. An example will explain it better: $ dak ls evince evince | 0.1.5-2sarge1 | oldstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc evince | 0.4.0-5 | etch-m68k | source, m68k evince | 0.4.0-5 | stable | source, alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc evince | 2.20.2-1 | testing | source evince | 2.20.2-1+b1 | testing | alpha, amd64, arm, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc evince | 2.22.2-1 | unstable | source, alpha, amd64, arm, armel, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc In this example, you can see that the version in unstable differs from the version
Duration : 0:8:9
http://packages.debian.org/sid/developers-reference – - 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 at the mail address arch@buildd.debian.org. 5.10.4. 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 within a reasonable amount of time. An example is a package that is SVGA-specific (only available for i386 and amd64), 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 http:// cvs.debian.org/srcdep/ Packages-arch-specific?cvsroot= dak; 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 their removal by filing a bug against ftp.debian.org 5.11. Non-Maintainer Uploads (NMUs) Under certain circumstances it is necessary for someone other than the official package maintainer to make a release of a package. This is called a non-maintainer upload, or NMU. This section handles only source NMUs, i.e. NMUs which upload a new version of the package. For binary-only NMUs by porters or QA members, please see Section 5.10.2.1, Recompilation or binary-only NMU . If a buildd builds and uploads a package, that too is strictly speaking a binary NMU. See Section 5.10.3.3, wanna-build for some more information. The main reason why NMUs are done is when a developer needs to fix another developer’s package in order to address serious problems or crippling bugs or when the package maintainer is unable to release a fix in a timely fashion. First and foremost, it is critical that NMU patches to source should be as non-disruptive as possible. Do not do housekeeping tasks, do not change the name of modules or files, do not move directories; in general, do not fix things which are not broken. Keep the patch as small as possible. If things bother you aesthetically, talk to the Debian maintainer, talk to the upstream maintainer, or submit a bug. However, aesthetic changes must not be made in a non-maintainer upload. And please remember the Hippocratic Oath: Above all, do no harm. It is better to leave a package with an open grave bug than applying a non-functional patch, or one that hides the bug instead of resolving it. 5.11.1. How to do a NMU NMUs which fix important, serious or higher severity bugs are encouraged and accepted. You should endeavor to reach the current maintainer of the package; they might be just about to upload a fix for the problem, or have a better solution. NMUs should be made to assist a package’s maintainer in resolving bugs. Maintainers should be thankful for that help, and NMUers should respect the decisions of maintainers, and try to personally help the maintainer by their work. A NMU should follow all conventions, written down in this section. For an upload to testing or unstable, this order of steps is recommended: * Make sure that the package’s bugs that the NMU is meant to address are all filed in the Debian Bug Tracking System (BTS). If they are not, submit them immediately. * Wait a few days for the response from the maintainer. If you don’t get any response, you may want to help them by sending the patch that fixes the bug. Don’t forget to tag the bug with the patch keyword.
Duration : 0:7:19
http://packages.debian.org/sid/developers-reference – - binary-only NMU as described in Section 5.10.2.1, Recompilation or binary-only NMU which doesn’t require any patch to be sent. If you want the package to be recompiled for all architectures, then you do a source NMU as usual and you will have to send a patch. Bugs fixed by source NMUs used to be tagged fixed instead of closed, but since version tracking is in place, such bugs are now also closed with the NMU version. Also, after doing an NMU, you have to send the information to the existing bugs that are fixed by your NMU, including the unified diff. Historically, it was custom to open a new bug and include a patch showing all the changes you have made. The normal maintainer will either apply the patch or employ an alternate method of fixing the problem. Sometimes bugs are fixed independently upstream, which is another good reason to back out an NMU’s patch. If the maintainer decides not to apply the NMU’s patch but to release a new version, the maintainer needs to ensure that the new upstream version really fixes each problem that was fixed in the non-maintainer release. In addition, the normal maintainer should always retain the entry in the changelog file documenting the non-maintainer upload — and of course, also keep the changes. If you revert some of the changes, please reopen the relevant bug reports. 5.11.5. Building source NMUs Source NMU packages are built normally. Pick a distribution using the same rules as found in Section 5.5, Picking a distribution , follow the other instructions in Section 5.6, Uploading a package . Make sure you do not change the value of the maintainer in the debian/control file. Your name as given in the NMU entry of the debian/changelog file will be used for signing the changes file. 5.11.6. Acknowledging an NMU If one of your packages has been NMU’ed, you have to incorporate the changes in your copy of the sources. This is easy, you just have to apply the patch that has been sent to you. Once this is done, you have to close the bugs that have been tagged fixed by the NMU. The easiest way is to use the -v option of dpkg-buildpackage, as this allows you to include just all changes since your last maintainer upload. Alternatively, you can close them manually by sending the required mails to the BTS or by adding the required closes: #nnnn in the changelog entry of your next upload. In any case, you should not be upset by the NMU. An NMU is not a personal attack against the maintainer. It is a proof that someone cares enough about the package that they were willing to help you in your work, so you should be thankful. You may also want to ask them if they would be interested in helping you on a more frequent basis as co-maintainer or backup maintainer (see Section 5.12, Collaborative maintenance ). 5.11.7. NMU vs QA uploads Unless you know the maintainer is still active, it is wise to check the package to see if it has been orphaned. The currentlist of orphaned packages which haven’t had their maintainer set correctly is available at http://qa.debian.org/ orphaned.html. If you perform an NMU on an improperly orphaned package, please set the maintainer to Debian QA Group [packages@qa.debian.org]. 5.11.8. Who can do an NMU Only official, registered Debian Developers can do binary or source NMUs. A Debian Developer is someone who has their key in the Debian key ring. Non-developers, however, are encouraged to download the source package and start hacking on it to fix problems; however, rather than doing an NMU, they should just submit worthwhile patches to the Bug Tracking System. Maintainers almost always appreciate quality patches and bug reports. 5.11.9. Terminology There are two new terms used throughout this section: “binary-only NMU” and “source NMU”. These terms are used with specific technical meaning throughout this document. Both binary-only and source NMUs are similar, since they involve an upload of a package by a developer who is not the official maintainer of that package. That is why it’s a non-maintainer upload. A source NMU is an upload of a package by a developer who is not the official maintainer, for the purposes of fixing a bug in the package. Source NMUs always involves changes to the source (even if it is just a change to debian/changelog). This can be either a change to the upstream source, or a change to the Debian bitsof the source. Note, however, that source NMUs may also include architecture-dependent packages, as well as an updated Debian diff. A binary-only NMU is a recompilation and upload of a binary package for a given architecture. As such, it is usually part of a porting effort. A binary-only NMU is a non-maintainer uploaded binary version of a package, with no source changes required. There are many cases where porters must fix problems in the
Duration : 0:7:22
http://packages.debian.org/sid/developers-reference – - sponsor by mailing the [debian-mentors@lists.debian.org] mailing list, describing your package and yourself and asking for a sponsor (see Section 7.5.1, Sponsoring packages and http: // people.debian.org/~mpalmer/ debian-mentors_FAQ.html for more information on sponsoring). On the other hand, if you are interested in porting Debian to alternative architectures or kernels you can subscribe to port specific mailing lists and ask there how to get started. Finally, if you are interested in documentation or Quality Assurance (QA) work you can join maintainers already working on these tasks and submit patches and improvements. One pitfall could be a too-generic local part in your mailadress: Terms like mail, admin, root, master should beavoided, please see http: //www.debian.org/MailingLists/ for details. 2.2. Debian mentors and sponsors The mailing list [debian-mentors@ lists.debian.org] has been set up for novice maintainers who seek help with initial packaging and other developer-related issues. Every new developer is invited to subscribe to that list (see Section 4.1, Mailing lists for details). Those who prefer one-on-one help (e.g., via private email) should also post to that list and an experienced developer will volunteer to help. In addition, if you have some packages ready for inclusion in Debian, but are waiting for your new maintainer application to go through, you might be able find a sponsor to upload your package for you. Sponsors are people who are official Debian Developers, and who are willing to criticize and upload your packages for you. Please read the unofficial debian-mentors FAQ at http://people.debian.org/ ~mpalmer/debian-mentors_ FAQ.html first. If you wish to be a mentor and/or sponsor, more information is available in Section 7.5, Interacting with prospective Debian developers . 2.3. Registering as a Debian developer Before you decide to register with Debian GNU/Linux, you will need to read all the information available at the New Maintainer’s Corner. It describes in detail the preparations you have to do before you can register to become a Debian developer. For example, before you apply, you have to read the Debian Social Contract. Registering as a developer means that you agree with and pledge to uphold the Debian Social Contract; it is very important that maintainers are in accord with the essential ideas behind Debian GNU/ Linux. Reading the GNU Manifesto would also be a good idea. The process of registering as a developer is a process of verifying your identity and intentions, and checking your technical skills. As the number of people working on Debian GNU/ Linux has grown to over 900 and our systems are used in several very important places, we have to be careful about being compromised. Therefore, we need to verify new maintainers before we can give them accounts on our servers and let them upload packages. Before you actually register you should have shown that you cando competent work and will be a good contributor. You show this by submitting patches through the Bug Tracking System and having a package sponsored by an existing Debian Developer for a while. Also, we expect that contributors are interested in the whole project and not just in maintaining their own packages. If you can help other maintainers by providing further information on a bug or even a patch, then do so! Registration requires that you are familiar with Debian’s philosophy and technical documentation. Furthermore, you need a GnuPG key which has been signed by an existing Debian maintainer. If your GnuPG key is not signed yet, you should try to meet a Debian Developer in person to get your key signed. There’s a GnuPG Key Signing Coordination page which should help you find a Debian Developer close to you. (If there is no Debian Developer close to you, alternative ways to pass the ID check may be permitted as an absolute exception on a case-by-case-basis. See the identification page for more information.) If you do not have an OpenPGP key yet, generate one. Every developer needs an OpenPGP key in order to sign and verify package uploads. You should read the manual for the software you are using, since it has much important information which is critical to its security. Many more security failures are due to human error than to software failure or high-powered spy techniques. See Section 3.2, Maintaining your public key for more information on maintaining your public key. Debian uses the GNU Privacy Guard (package gnupg version 1 or better) as its baseline standard. You can use some other implementation of OpenPGP as well. Note that OpenPGP is an open standard based on RFC 2440. You need a version 4 key for use in Debian Development. Your key length must be at least 1024 bits; there is no reason to use a smaller key, and doing
Duration : 0:7:30
http://packages.debian.org/sid/developers-reference – - this server are described in the BTS control server documentation. 5.8.1. Monitoring bugs If you want to be a good maintainer, you should periodically check the Debian bug tracking system (BTS) for your packages. The BTS contains all the open bugs against your packages. You can check them by browsing this page: http://bugs.debian.org/ yourlogin@debian.org. Maintainers interact with the BTS via email addresses at bugs.debian.org. Documentation on available commands can be found at http://www.debian.org/ Bugs/, or, if you have installed the doc-debian package, you can look at the local files /usr/ share/doc/debian/bug-*. Some find it useful to get periodic reports on open bugs. You can add a cron job such as the following if you want to get a weekly email outlining all the open bugs against your packages: # ask for weekly reports of bugs in my packages 0 17 * * fri echo “index maint address” | mail request@bugs.debian.org Replace address with your official Debian maintainer address. 5.8.2. Responding to bugs When responding to bugs, make sure that any discussion you have about bugs is sent both to the original submitter of the bug, and to the bug itself (e.g., [123@bugs.debian.org]) . If you’re writing a new mail and you don’t remember the submitter email address, you can use the [123-submitter@bugs.debian.org] email to contact the submitter and to record your mail within the buglog (that means you don’t need to send a copy of the mail to [ 123@bugs.debian.org]). If you get a bug which mentions FTBFS, this means Fails to build from source. Porters frequently use this acronym. Once you’ve dealt with a bug report (e.g. fixed it), mark it as done (close it) by sending an explanation message to [ 123-done@bugs.debian.org]. If you’re fixing a bug by changing and uploading the package, you can automate bug closing as described in Section 5.8.4, When bugs are closed by new uploads . You should never close bugs via the bug server close command sent to [control@bugs.debian.org]. If you do so, the original submitter will not receive any information about why the bug was closed. 5.8.3. Bug housekeepingAs a package maintainer, you will often find bugs in other packages or have bugs reported against your packages which are actually bugs in other packages. The bug tracking system’s features are described in the BTS documentation for Debian developers. Operations such as reassigning, merging, and tagging bug reports are described in the BTS control server documentation. This section contains some guidelines for managing your own bugs, based on the collective Debian developer experience. Filing bugs for problems that you find in other packages is one of the civic obligations of maintainership, see Section 7.1, Bug reporting for details. However, handling the bugs in your own packages is even more important. Here’s a list of steps that you may follow to handle a bug report: 1. Decide whether the report corresponds to a real bug or not. Sometimes users are just calling a program in the wrong way because they haven’t read the documentation. If you diagnose this, just close the bug with enough information to let the user correct their problem (give pointers to the good documentation and so on). If the same report comes up again and again you may ask yourself if the documentation is good enough or if the program shouldn’t detect its misuse in order to give an informative error message. This is an issue that may need to be brought up with the upstream author. If the bug submitter disagrees with your decision to close the bug, they may reopen it until you find an agreement on how to handle it. If you don’t find any, you may want to tag the bug wontfix to let people know that the bug exists but that it won’t be corrected. If this situation is unacceptable, you (or the submitter) may want to require a decision of the technical committee by reassigning the bug to tech-ctte (you may use the clone command of the BTS if you wish to keep it reported against your package). Before doing so, please read the recommended procedure. 2. If the bug is real but it’s caused by another package, just reassign the bug to the right package. If you don’t know which package it should be reassigned to, you should ask for help on IRC or on [debian-devel@lists.debian.org]. Please inform the maintainer( s) of the package you reassign the bug to, for example by Cc:ing the message that does the reassign to [packagename@packages.debian.org] and explaining your reasons in that mail. Please note that a simple reassignment is not e-mailed to the maintainers of the package being reassigned to, so they won’t know about it until they look at a bug overview for their packages.
Duration : 0:7:26
http://packages.debian.org/sid/developers-reference – - is uploaded multiple times per day to ftp-master.debian.org. With a fairly recent dput, this section [tfheen_delayed] method = scp fqdn = gluck.debian.org incoming = ~tfheen in ~/.dput.cf should work fine for uploading to the DELAYED queue. Note: Since this upload queue goes to ftp-master.debian.org, the prescription found in Section 5.6.1, Uploading to ftp-master applies here as well. 5.6.3. Security uploads Do NOT upload a package to the security upload queue (oldstable-security, stable-security , etc.) without prior authorization from the security team. If the package does not exactly meet the team’s requirements, it will cause many problems and delays in dealing with the unwanted upload. For details, please see section Section 5.8.5, Handling security-related bugs . 5.6.4. Other upload queues The scp queues on ftp-master.debian.org, and security.debian.org are mostly unusable due to the login restrictions on those hosts. The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are currently down. Work is underway to resurrect them. The queues on master.debian.org, samosa.debian.org, master.debian.or.jp, and ftp.chiark.greenend.org.uk are down permanently, and will not be resurrected. The queue in Japan will be replaced with a new queue on hp.debian.or.jp some day. 5.6.5. Notification that a new package has been installed The Debian archive maintainers are responsible for handling package uploads. For the most part, uploads are automatically handled on a daily basis by the archive maintenance tools, katie . Specifically, updates to existing packages to the unstable distribution are handled automatically. In other cases, notably new packages, placing the uploaded package into the distribution is handled manually. When uploads are handled manually, the change to the archive may take up to a month to occur. Please be patient. In any case, you will receive an email notification indicating that the package has been added to the archive, which also indicates which bugs will be closed by the upload. Please examine this notification carefully, checking if any bugs you meant to close didn’t get triggered.The installation notification also includes information on what section the package was inserted into. If there is a disparity, you will receive a separate email notifying you of that. Read on below. Note that if you upload via queues, the queue daemon software will also send you a notification by email. 5.7. Specifying the package section, subsection and priority The debian/control file’s Section and Priority fields do not actually specify where the file will be placed in the archive, nor its priority. In order to retain the overall integrity of the archive, it is the archive maintainers who have control over these fields. The values in the debian/control file are actuallyjust hints. The archive maintainers keep track of the canonical sections and priorities for packages in the override file. If there is a disparity between the override file and the package’s fields as indicated in debian/control, then you will receive an email noting the divergence when the package is installed into the archive. You can either correct your debian/control file for your next upload, or else you may wish to make a change in the override file. To alter the actual section that a package is put in, you need to first make sure that the debian/control file in your package is accurate. Next, send an email [override-change@ debian.org] or submit a bug against ftp.debian.org requesting that the section 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 dpkg-scanpackages (1) and http://www.debian.org/ Bugs/Developer#maintincorrect. Note that the Section field describes both the section as well as the subsection, which are described in Section 4.6.1, Sections . If the section is main, it should be omitted. The list of allowable subsections can be found in http: // www.debian.org/doc/debian-policy/ ch-archive.html#s-subsections. 5.8. Handling bugs Every developer has to be able to work with the Debian bug tracking system. This includes knowing how to file bug reports properly (see Section 7.1, Bug reporting ), how to update them and reorder them, and how to process and close them. The bug tracking system’s features are described in the BTS documentation for developers. This includes closing bugs, sending followup messages, assigning severities and tags, marking bugs as forwarded, and other issues. Operations such as reassigning bugs to other packages, merging separate bug reports about the same issue, or reopening bugs when they are prematurely closed, are handled using the so-called control mail server. All of the commands available on
Duration : 0:7:52
http://packages.debian.org/sid/developers-reference – - Debian in general is #debian. This is a large, general-purpose channel where users can find recent news in the topic and served by bots. #debian is for English speakers; there are also #debian.de, #debian-fr, #debian-br and other similarly named channels for speakers of other languages. The main channel for Debian development is #debian-devel. It is a very active channel since usually over 150 people are always logged in. It’s a channel for people who work on Debian, it’s not a support channel (there’s #debian for that). It is however open to anyone who wants to lurk (and learn). Its topic is commonly full of interesting information for developers. Since #debian-devel is an open channel, you should not speak there of issues that are discussed in [ debian-private@lists.debian.org]. There’s another channel for this purpose, it’s called #debian-private and it’s protected by a key. This key is available in the archives of debian-private in master.debian.org: ~debian/archive/debian-private/ , just zgrep for #debian-private in all the files. There are other additional channels dedicated to specific subjects. #debian-bugs is used for coordinating bug squashing parties. #debian-boot is used to coordinate the work on the debian-installer. #debian-doc is occasionally used to talk about documentation, like the document you are reading. Other channels are dedicated to an architecture or a set of packages: # debian-kde, #debian-dpkg, #debian-jr, #debian-edu, #debian-oo (OpenOffice package) … Some non-English developers’ channels exist as well, for example #debian-devel-fr for French speaking people interested in Debian’s development. Channels dedicated to Debian also exist on other IRC networks, notably on the freenode IRC network, which was pointed at by the irc.debian.org alias until 4th June 2006. To get a cloak on freenode, you send Jörg Jaspert [joerg@debian.org] a signed mail where you tell what your nick is. Put cloak somewhere in the Subject: header. The nick should be registered: Nick Setup Page. The mail needs to be signed by a key in the Debian keyring. Please see Freenodes documentation for more information about cloaks. 4.3. Documentation This document contains a lot of information which is useful to Debian developers, but it cannot contain everything. Most of the other interesting documents are linked from The Developers’ Corner. Take the time to browse all the links, you will learn many more things. 4.4. Debian machines Debian has several computers working as servers, most of which serve critical functions in the Debian project. Most of the machines are used for porting activities, and they all have a permanent connection to the Internet. Some of the machines are available for individual developers to use, as long as the developers follow the rules set forth in the Debian Machine Usage Policies. Generally speaking, you can use these machines for Debian-related purposes as you see fit. Please be kind to system administrators, and do not use up tons and tons of disk space, network bandwidth, or CPU without first getting the approval of the system administrators. Usually these machines are run by volunteers. Please take care to protect your Debian passwords and SSH keys installed on Debian machines. Avoid login or upload methods which send passwords over the Internet in the clear, such as telnet, FTP, POP etc. Please do not put any material that doesn’t relate to Debian on the Debian servers, unless you have prior permission. The current list of Debian machines is available at http:// db.debian.org/machines.cgi. That web page contains machine names, contact information, information about who can log in, SSH keys etc. If you have a problem with the operation of a Debian server, and you think that the system operators need to be notified of this problem, you can check the list of open issues in the DSA queue of our request tracker at https://rt.debian.org/ (you can login with user “guest” and password “readonly”). To report a new problem, simply send a mail to [admin@rt.debian.org] and make sure to put the string “Debian RT” somewhere in the subject. If you have a problem with a certain service, not related to the system administration (such as packages to be removed from the archive, suggestions for the web site, etc.), generally you’ll report a bug against a “pseudo-package”. See Section 7.1, Bug reporting for information on how to submit bugs.Some of the core servers are restricted, but the information from there is mirrored to another server. 4.4.1. The bugs server bugs.debian.org is the canonical location for the Bug Tracking System (BTS). It is restricted; a mirror is available on merkel. If you plan on doing some statistical analysis or processing of Debian bugs, this would be the place to do it. Please describe your plans on [debian-devel@
Duration : 0:7:34
http://packages.debian.org/sid/developers-reference – - add-on to should be put in here. * Why should I want this package? This is related to the above, but not the same (this is a mail user agent; this is cool, fast, interfaces with PGP and LDAP and IMAP, has features X, Y, and Z). * If this package should not be installed directly, but is pulled in by another package, this should be mentioned. * If the package is experimental, or there are other reasons it should not be used, if there are other packages that should be used instead, it should be here as well. * How is this package different from the competition? Is it a better implementation? more features? different features? Why should I choose this package. 6.2.4.**Upstream home page We recommend that you add the URL for the package’s home page in the Homepage field of the Source section in debian/control. Adding this information in the package description itself is considered deprecated. 6.2.5.**Version Control System location There are additional fields for the location of the Version Control System in debian/control. 6.2.5.1.**Vcs-Browser Value of this field should be a http:// URL pointing to a web-browsable copy of the Version Control System repository used to maintain the given package, if available. The information is meant to be useful for the final user, willing to browse the latest work done on the package (e.g. when looking for the patch fixing a bug tagged as pending in the bug tracking system). 6.2.5.2.**Vcs-* Value of this field should be a string identifying unequivocally the location of the Version Control System repository used to maintain the given package, if available. * identify the Version Control System; currently the following systems are supported by the package tracking system: arch, bzr (Bazaar) , cvs, darcs, git, hg (Mercurial), mtn (Monotone), svn ( Subversion). It is allowed to specify different VCS fields for the same package: they will all be shown in the PTS web interface. The information is meant to be useful for a user knowledgeable in the given Version Control System and willing to build the current version of a package from the VCS sources. Other uses of this information might include automatic building of the latest VCS version of the given package. To this end the location pointed to by the field should better be version agnostic and point to the main branch (for VCSs supporting such a concept). Also, the location pointed to should be accessible to the final user; fulfilling this requirement might imply pointing to an anonymous access of the repository instead of pointing to an SSH-accessible version of the same. In the following example, an instance of the field for a Subversion repository of the vim package is shown. Note how the URL is in the svn:// scheme (instead of svn+ssh: //) and how it points to the trunk/ branch. The use of the Vcs-Browser and Homepage fields described above is also shown. Source: vim Section: editors Priority: optional [snip] Vcs-Svn: svn://svn.debian.org/ svn/pkg-vim/trunk/packages/ vim Vcs-Browser: http:/ /svn.debian.org/wsvn/ pkg-vim/trunk/packages/ vim Homepage: http://www.vim.org 6.3.**Best practices for debian/changelog The following practices supplement the Policy on changelog files . 6.3.1.**Writing useful changelog entries The changelog entry for a package revision documents changes in that revision, and only them. Concentrate on describing significant and user-visible changes that were made since the last version. Focus on what was changed *** who, how and when are usually less important. Having said that, remember to politely attribute people who have provided notable help in making the package (e.g., those who have sent in patches). There’s no need to elaborate the trivial and obvious changes. You can also aggregate several changes in one entry. On the other hand, don’t be overly terse if you have undertaken a major change. Be especially clear if there are changes that affect the behaviour of the program. For further explanations, use the README.Debian file. Use common English so that the majority of readers can comprehend it. Avoid abbreviations, tech-speak and jargon when explaining changes that close bugs, especially for bugs filed by users that did not strike you as particularly technically savvy. Be polite, don’t swear. It is sometimes desirable to prefix changelog entries with the names of the files that were changed. However, there’s no need to explicitly list each and every last one of the changed files, especially if the change was small or repetitive. You may use wildcards. When referring to bugs, don’t assume anything. Say what the problem was, how it was fixed, and append the closes: #nnnnn string. See Section** 5.8.4, ***When bugs are closed by new uploads* ** for more information. 6.3.2.**Common misconceptions
Duration : 0:7:46