Software Bug Tracking » debian

dbdvrf #30 Debian Developer’s Reference

admin — Fri, 02 Apr 2010 15:33:19 +0000

http://packages.debian.org/sid/developers-reference – - source in order to get them to compile for their target architecture; that would be considered a source NMU rather than a binary-only NMU. As you can see, we don’t distinguish in terminology between porter NMUs and non-porter NMUs. Both classes of NMUs, source and binary-only, can be lumped under the term “NMU”. However, this often leads to confusion, since most people think “source NMU” when they think “NMU”. So it’s best to be careful: always use “binary NMU” or “binNMU” for binary-only NMUs. 5.12. Collaborative maintenance Collaborative maintenance is a term describing the sharing of Debian package maintenance duties by several people. This collaboration is almost always a good idea, since it generally results in higher quality and faster bug fix turnaround times. It is strongly recommended that packages with a priority of Standard or which are part of the base set have co-maintainers. Generally there is a primary maintainer and one or more co-maintainers. The primary maintainer is the person whose name is listed in the Maintainer field of the debian/control file. Co-maintainers are all the other maintainers, usually listed in the Uploaders field of the debian/control file. In its most basic form, the process of adding a new co-maintainer is quite easy: * Setup the co-maintainer with access to the sources you build the package from. Generally this implies you are using a network-capable version control system, such as CVS or Subversion. Alioth (see Section 4.12, Debian’s GForge installation: Alioth ) provides such tools, amongst others. * Add the co-maintainer’s correct maintainer name and address to the Uploaders field in the first paragraph of the debian/ control file. Uploaders: John Buzz [jbuzz@debian.org], Adam Rex [arex@debian.org] * Using the PTS (Section 4.10, The Package Tracking System ), the co-maintainers should subscribe themselves to the appropriate source package. Another form of collaborative maintenance is team maintenance, which is recommended if you maintain several packages with the same group of developers. In that case, the Maintainer and Uploaders field of each package must be managed with care. It isrecommended to choose between one of the two following schemes: 1. Put the team member mainly responsible for the package in the Maintainer field. In the Uploaders, put the mailing list address, and the team members who care for the package. 2. Put the mailing list address in the Maintainer field. In the Uploaders field, put the team members who care for the package. In this case, you must make sure the mailing list accept bug reports without any human interaction (like moderation for non-subscribers). In any case, it is a bad idea to automatically put all team members in the Uploaders field. It clutters the Developer’s Package Overview listing (see Section 4.11, Developer’s packages overview ) with packages one doesn’t really care for, and creates a false sense of good maintenance. 5.13. The testing distribution 5.13.1. Basics Packages are usually installed into the testing distribution after they have undergone some degree of testing in unstable. They must be in sync on all architectures and mustn’t have dependencies that make them uninstallable; they also have to have generally no known release-critical bugs at the time they’re installed into testing . This way, testing should always be close to being a release candidate. Please see below for details. 5.13.2. Updates from unstable The scripts that update the testing distribution are run twice each day, right after the installation of the updated packages; these scripts are called britney. They generate the Packages files for the testing distribution, but they do so in an intelligent manner; they try to avoid any inconsistency and to use only non-buggy packages. The inclusion of a package from unstable is conditional on the following: * The package must have been available in unstable for 2, 5 or 10 days, depending on the urgency (high, medium or low). Please note that the urgency is sticky, meaning that the highest urgency uploaded since the previous testing transition is taken into account. Those delays may be doubled during a freeze, or testing transitions may be switched off altogether; * It must not have new release-critical bugs (RC bugs affecting the version available in unstable, but not affecting the version in testing); * It must be available on all architectures on which it has previously been built in unstable. Section 4.9.2, The dak ls utility may be of interest to check that information; * It must not break any dependency of a package which is already available in testing; * The packages on which

Duration : 0:7:9

Technorati Tags: debian, developers, reference

dbdvrf #45 Debian Developer’s Reference

admin — Tue, 30 Mar 2010 18:12:32 +0000

http://packages.debian.org/sid/developers-reference – - to the original filename. Note that you don’t need to depend on sharutils to get the uudecode program if you use perl’s pack function. The code could look like uuencode-file: perl -ne ‘print(pack “u”, $$_);’ $(file) ] $(file).uuencoded uudecode-file: perl -ne ‘print(unpack “u”, $$_);’ $(file).uuencoded ] $(file) Chapter**7.**Beyond Packaging Debian is about a lot more than just packaging software and maintaining those packages. This chapter contains information about ways, often really critical ways, to contribute to Debian beyond simply creating and maintaining packages. As a volunteer organization, Debian relies on the discretion of its members in choosing what they want to work on and in choosing the most critical thing to spend their time on. 7.1.**Bug reporting We encourage you to file bugs as you find them in Debian packages. In fact, Debian developers are often the first line testers. Finding and reporting bugs in other developers’ packages improves the quality of Debian. Read the instructions for reporting bugs in the Debian bug tracking system. Try to submit the bug from a normal user account at which you are likely to receive mail, so that people can reach you if they need further information about the bug. Do not submit bugs as root. You can use a tool like reportbug(1) to submit bugs. It can automate and generally ease the process. Make sure the bug is not already filed against a package. Each package has a bug list easily reachable at http:// bugs.debian.org/packagename Utilities like querybts( 1) can also provide you with this information (and reportbug will usually invoke querybts before sending, too). Try to direct your bugs to the proper location. When for example your bug is about a package which overwrites files from another package, check the bug lists for both of those packages in order to avoid filing duplicate bug reports. For extra credit, you can go through other packages, merging bugs which are reported more than once, or tagging bugs `fixed’ when they have already been fixed. Note that when you are neither the bug submitter nor the package maintainer, you should not actually close the bug (unless you secure permission fromthe maintainer). From time to time you may want to check what has been going on with the bug reports that you submitted. Take this opportunity to close those that you can’t reproduce anymore. To find out all the bugs you submitted, you just have to visit http:// bugs.debian.org/from:[your-email-addr]. 7.1.1.**Reporting lots of bugs at once (mass bug filing) Reporting a great number of bugs for the same problem on a great number of different packages *** i.e., more than 10 *** is a deprecated practice. Take all possible steps to avoid submitting bulk bugs at all. For instance, if checking for the problem can be automated, add a new check to lintian so that an error or warning is emitted. If you report more than 10 bugs on the same topic at once, it is recommended that you send a message to [ debian-devel@lists.debian.org] describing your intention before submitting the report, and mentioning the fact in the subject of your mail. This will allow other developers to verify that the bug is a real problem. In addition, it will help prevent a situation in which several maintainers start filing the same bug report simultaneously. Please use the programms dd-list and if appropriate whodepends (from the package devscripts) to generate a list of all affected packages, and include the output in your mail to [ debian-devel@lists.debian.org]. Note that when sending lots of bugs on the same subject, you should send the bug report to [maintonly@bugs.debian.org] so that the bug report is not forwarded to the bug distribution mailing list. 7.2.**Quality Assurance effort 7.2.1.**Daily work Even though there is a dedicated group of people for Quality Assurance, QA duties are not reserved solely for them. You can participate in this effort by keeping your packages as bug-free as possible, and as lintian-clean (see Section**A.2.1, ***lintian*** ) as possible. If you do not find that possible, then you should consider orphaning some of your packages (see Section**5.9.4, ***Orphaning a package* ** ). Alternatively, you may ask the help of other people in order to catch up with the backlog of bugs that you have (you can ask for help on [debian-qa@lists.debian.org] or [debian-devel@lists.debian.org]) . At the same time, you can look for co-maintainers (see Section**5.12, * **Collaborative maintenance*** ). 7.2.2.**Bug squashing parties From time to time the QA group organizes bug squashing parties to get rid of as many problems as possible. They are announced on [debian-devel-announce@ lists.debian.org] and the announcement explains which area will be the focus of the party: usually they focus on release critical bugs but it may happen

Duration : 0:7:29

Technorati Tags: debian, developers, reference

dbdvrf #24 Debian Developer’s Reference

admin — Sat, 27 Mar 2010 19:46:30 +0000

http://packages.debian.org/sid/developers-reference – - 5.9.4. Orphaning a package If you can no longer maintain a package, you need to inform others, and see that the package is marked as orphaned. You should set the package maintainer to Debian QA Group [packages@qa.debian.org] and submit a bug report against the pseudo package wnpp. The bug report should be titled O: package — short description indicating that the package is now orphaned. The severity of the bug should be set to normal; if the package has a priority of standard or higher, it should be set to important. If you feel it’s necessary, send a copy to [ debian-devel@lists.debian.org] by putting the address in the X-Debbugs-CC: header of the message (no, don’t use CC:, because that way the message’s subject won’t indicate the bug number). If you just intend to give the package away, but you can keep maintainership for the moment, then you should instead submit a bug against wnpp and title it RFA: package — short description. RFA stands for Request For Adoption. More information is on the WNPP web pages. 5.9.5. Adopting a package A list of packages in need of a new maintainer is available in the Work-Needing and Prospective Packages list (WNPP). If you wish to take over maintenance of any of the packages listed in the WNPP, please take a look at the aforementioned page for information and procedures. It is not OK to simply take over a package that you feel is neglected — that would be package hijacking. You can, of course,contact the current maintainer and ask them if you may take over the package. If you have reason to believe a maintainer has gone AWOL (absent without leave), see Section 7.4, Dealing with inactive and/or unreachable maintainers . Generally, you may not take over the package without the assent of the current maintainer. Even if they ignore you, that is still not grounds to take over a package. Complaints about maintainers should be brought up on the developers’ mailing list. If the discussion doesn’t end with a positive conclusion, and the issue is of a technical nature, consider bringing it to the attention of the technical committee ( see the technical committee web page for more information). If you take over an old package, you probably want to be listed as the package’s official maintainer in the bug system. This will happen automatically once you upload a new version with an updated Maintainer: field, although it can take a few hours after the upload is done. If you do not expect to upload a new version for a while, you can use Section 4.10, The Package Tracking System to get the bug reports. However, make sure that the old maintainer has no problem with the fact that they will continue to receive the bugs during that time. 5.10. Porting and being ported Debian supports an ever-increasing number of architectures. Even if you are not a porter, and you don’t use any architecture but one, it is part of your duty as a maintainer to be aware of issues of portability. Therefore, even if you are not a porter, you should read most of this chapter. Porting is the act of building Debian packages for architectures that are different from the original architecture of the package maintainer’s binary package. It is a unique and essential activity. In fact, porters do most of the actual compiling of Debian packages. For instance, when a maintainer uploads a (portable) source packages with binaries for the i386 architecture, it will be built for each of the other architectures, amounting to 12 more builds. 5.10.1. Being kind to porters Porters have a difficult and unique task, since they are required to deal with a large volume of packages. Ideally, every source package should build right out of the box. Unfortunately, this is often not the case. This section contains a checklist of “gotchas” often committed by Debian maintainers — common problems which often stymie porters, and make their jobs unnecessarily difficult. The first and most important thing is to respond quickly to bug or issues raised by porters. Please treat porters with courtesy, as if they were in fact co-maintainers of your package (which, in a way, they are). Please be tolerant of succinct or even unclear bug reports; do your best to hunt down whatever the problem is. By far, most of the problems encountered by porters are caused by packaging bugs in the source packages. Here is a checklist of things you should check or be aware of. 1. Make sure that your Build-Depends and Build-Depends-Indep settings in debian/ control are set properly. The best way to validate this is to use the debootstrap package to create an unstable chroot environment (see Section A.4.2, debootstrap ). Within that chrooted environment, install the build-essential package and any package dependencies mentioned in Build-Depends

Duration : 0:7:14

Technorati Tags: debian, developers, reference

dbdvrf #4 Debian Developer’s Reference

admin — Thu, 18 Mar 2010 16:11:45 +0000

http://packages.debian.org/sid/developers-reference – - key, the Keyring Maintainers might reject the new key. Details can be found at http: //keyring.debian.org/ replacing_keys.html. The same key extraction routines discussed in Section 2.3, Registering as a Debian developer apply. You can find a more in-depth discussion of Debian key maintenance in the documentation of the debian-keyring package. 3.3. Voting Even though Debian isn’t really a democracy, we use a democratic process to elect our leaders and to approve general resolutions. These procedures are defined by the Debian Constitution. Other than the yearly leader election, votes are not routinely held, and they are not undertaken lightly. Each proposal is first discussed on the [debian-vote@lists.debian.org] mailing list and it requires several endorsements before the project secretary starts the voting procedure. You don’t have to track the pre-vote discussions, as the secretary will issue several calls for votes on [ debian-devel-announce@ lists.debian.org] (and all developers are expected to be subscribed to that list). Democracy doesn’t work well if people don’t take part in the vote, which is why we encourage all developers to vote. Voting is conducted via GPG-signed/encrypted email messages. The list of all proposals (past and current) is available on the Debian Voting Information page, along with information on how to make, second and vote on proposals. 3.4. Going on vacation gracefullyIt is common for developers to have periods of absence, whether those are planned vacations or simply being buried in other work. The important thing to notice is that other developers need to know that you’re on vacation so that they can do whatever is needed if a problem occurs with your packages or other duties in the project. Usually this means that other developers are allowed to NMU (see Section 5.11, Non-Maintainer Uploads (NMUs) ) your package if a big problem (release critical bug, security update, etc.) occurs while you’re on vacation. Sometimes it’s nothing as critical as that, but it’s still appropriate to let others know that you’re unavailable. In order to inform the other developers, there are two thingsthat you should do. First send a mail to [ debian-private@lists.debian.org] with [VAC] prepended to the subject of your message^[ 2] and state the period of time when you will be on vacation. You can also give some special instructions on what to do if a problem occurs. The other thing to do is to mark yourself as on vacation in the Debian developers’ LDAP database (this information is only accessible to Debian developers). Don’t forget to remove the on vacation flag when you come back! Ideally, you should sign up at the GPG coordination site when booking a holiday and check if anyone there is looking for signing. This is especially important when people go to exotic places where we don’t have any developers yet but where there are people who are interested in applying. 3.5. Coordination with upstream developers A big part of your job as Debian maintainer will be to stay in contact with the upstream developers. Debian users will sometimes report bugs that are not specific to Debian to our bug tracking system. You have to forward these bug reports to the upstream developers so that they can be fixed in a future upstream release. While it’s not your job to fix non-Debian specific bugs, you may freely do so if you’re able. When you make such fixes, be sure to pass them on to the upstream maintainers as well. Debian users and developers will sometimes submit patches to fix upstream bugs — you should evaluate and forward these patches upstream. If you need to modify the upstream sources in order to build a policy compliant package, then you should propose a nice fix to the upstream developers which can be included there, so that you won’t have to modify the sources of the next upstream version. Whatever changes you need, always try not to fork from the upstream sources. 3.6. Managing release-critical bugs Generally you should deal with bug reports on your packages as described in Section 5.8, Handling bugs . However, there’s a special category of bugs that you need to take care of — the so-called release-critical bugs (RC bugs). All bug reports that have severity critical, grave or serious are considered to have an impact on whether the package can be released in the next stable release of Debian. These bugs can delay the Debian release and/or can justify the removal of a package at freeze time. That’s why these bugs need to be corrected as quickly as possible. Developers who are part of the Quality Assurance group are following all such bugs, and trying to help whenever possible. If, for any reason, you aren’t able fix an RC bug in a package of yours within 2 weeks, you should either ask for help by sending a mail to the

Duration : 0:7:13

Technorati Tags: debian, developers, reference

dbdvrf #14 Debian Developer’s Reference

admin — Tue, 09 Mar 2010 19:26:10 +0000

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

Technorati Tags: debian, developers, reference

dbdvrf #46 Debian Developer’s Reference

admin — Sun, 17 Jan 2010 17:48:31 +0000

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

Technorati Tags: debian, developers, reference

dbdvrf #11 Debian Developer’s Reference

admin — Sat, 02 Jan 2010 21:25:38 +0000

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

Technorati Tags: debian, developers, reference

dbdvrf #27 Debian Developer’s Reference

admin — Fri, 25 Dec 2009 07:26:40 +0000

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

Technorati Tags: debian, developers, reference

dbdvrf #29 Debian Developer’s Reference

admin — Sun, 20 Dec 2009 21:56:38 +0000

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

Technorati Tags: debian, developers, reference

dbdvrf #2 Debian Developer’s Reference

admin — Sun, 13 Dec 2009 02:01:30 +0000

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

Technorati Tags: debian, developers, reference