doc-debian-6.1/0000775000000000000000000000000012040336463010236 5ustar doc-debian-6.1/doc/0000775000000000000000000000000012060350761011002 5ustar doc-debian-6.1/doc/mailing-lists.txt0000664000000000000000000015653212060350761014333 0ustar Introduction to the Debian mailing lists ======================================== Debian GNU/Linux is developed through distributed development all around the world. Therefore, email is the preferred way to discuss various items. Much of the conversation between Debian developers and users is managed through several mailing lists. There are many world-open mailing lists, meaning anyone can read everything that is posted, and participate in the discussions. Everyone is encouraged to help development of Debian and to spread the word of free software. There are also a few lists which are only open to official Debian developers; please don't interpret this as closed development, it sometimes doesn't make much sense discussing internal topics with non-developers. All original Debian mailing lists run on a special server, using an automatic mail processing software called SmartList. This server is called lists.debian.org. All submission, subscription and unsubscription messages have to be sent to a particular address at this host. The language used on all lists is English, unless stated otherwise. There are some user lists for other languages available. Subscription / Unsubscription ----------------------------- Anyone is able to subscribe/unsubscribe on their own to any mailing list, presuming the subscription policy for a particular list is `open'. The requests for subscription or unsubscription can be sent to a special control address, which is slightly different from the list address. Subscription or unsubscription messages should NOT be sent to the address of the mailing list itself. To subscribe or unsubscribe from a mailing list, please send mail to -REQUEST@lists.debian.org with the word `subscribe' or `unsubscribe' as subject. Please remember the -REQUEST part of the address. As part of the subscription process, the list software will send you an email to which you must reply in order to finish subscribing. This is a security measure to keep people from subscribing others to the lists without their permission. If you need to contact a human listmaster, direct your mail to listmaster@lists.debian.org . To find out who is responsible for the lists, take a look at http://www.debian.org/intro/organization User lists There are several user based mailing lists where developers and users can get in contact to discuss and solve problems. debian-announce@lists.debian.org Description : Major news and very important changes in the project are announced here. Moderated : yes Subscription: open debian-chinese-big5@lists.debian.org Description : Debian Chinese Project: Chinese localization (l10n), documentation and web site translation, user support etc. Posts may be in English or Big5-encoded Chinese. All posts are automatically converted to GB encoding and cross-posted to the debian-chinese-gb mailing list. If you would rather read and post in GB-encoded Chinese, please subscribe to debian-chinese-gb instead. Language : Chinese Moderated : subscribers Subscription: open debian-chinese-gb@lists.debian.org Description : Debian Chinese Project: Chinese localization (l10n) issues, documentation and web site translation, user support etc. Posts may be in English or GB-encoded Chinese. All posts are automatically converted to Big5 encoding and cross-posted to the debian-chinese-big5 mailing list. If you would rather read and post in Big5-encoded Chinese, please subscribe to debian-chinese-big5 instead. Language : Chinese Moderated : subscribers Subscription: open debian-commercial@lists.debian.org Description : Information about Debian related products from software and hardware vendors is published here. This is a moderated list, so please send your submissions to the moderator at press@debian.org. Please note that posting commercial posts to any other Debian mailing list is not permitted. Moderated : yes Subscription: open debian-esperanto@lists.debian.org Description : Debian users who speak Esperanto. Language : Esperanto Moderated : no Subscription: open debian-firewall@lists.debian.org Description : Discussion of implementation and maintenance of firewalls using Debian. Both basic issues and new more exotic developments are discussed here. Moderated : no Subscription: open debian-isp@lists.debian.org Description : Discussion about issues and problems specific to Internet Service Providers (ISPs for short) that use Debian. Moderated : no Subscription: open debian-italian@lists.debian.org Description : Support for Debian users that speak Italian. (High-volume mailing list.) Language : Italian Moderated : no Subscription: open debian-japanese@lists.debian.org Description : Support for Debian users that speak Japanese, Japanese localization issues, integrating Debian JP packages into Debian etc. The English language is allowed, but using Japanese is encouraged even for those who aren't native speakers. For native Japanese, Debian JP Project provides several mailing lists discussing the Debian system in Japanese, see http://www.debian.or.jp/MailingList.html Language : English/Japanese Moderated : no Subscription: open debian-kde@lists.debian.org Description : Discussions related to KDE in Debian. Those developing KDE-based packages are encouraged to use this to discuss issues and share their experience. Moderated : no Subscription: open debian-laptop@lists.debian.org Description : Installing, updating and using laptops with Debian. Suggestions on special packaging, complaints, etc. are welcome. Moderated : no Subscription: open debian-news-french@lists.debian.org Description : News about Debian for users speaking French. Language : French Moderated : yes Subscription: open debian-news-german@lists.debian.org Description : News about Debian for users speaking German. Language : German Moderated : yes Subscription: open debian-news-italian@lists.debian.org Description : Releases, news, internationalization efforts and other related news about Debian for Italian-speaking users. Language : Italian Moderated : yes Subscription: open debian-news-portuguese@lists.debian.org Description : Releases, news, internationalization efforts and other related news about Debian for users speaking Portuguese. Language : Portuguese Moderated : yes Subscription: open debian-news-spanish@lists.debian.org Description : Releases, news, internationalization efforts and other related news about Debian for Spanish-speaking users. Language : Spanish Moderated : yes Subscription: open debian-news@lists.debian.org Description : General news about the distribution and the project. The current events and news about Debian are summarized in the Debian Weekly News, a newsletter regularly posted on this list. Moderated : yes Subscription: open debian-russian@lists.debian.org Description : Support for Debian users that speak Russian, and Russian localization issues: translating "po" files, coordinating patches for Debian packages to work with the Russian language. Language : Russian Moderated : no Subscription: open debian-security-announce@lists.debian.org Description : The security team informs the users about security problems by posting security advisories about Debian packages on this list. Moderated : yes Subscription: open debian-user-catalan@lists.debian.org Description : Support for Debian users that speak Catalan. Language : Catalan Moderated : no Subscription: open debian-user-danish@lists.debian.org Description : Support for Debian users who speak Danish. Language : Danish Moderated : no Subscription: open debian-user-french@lists.debian.org Description : Support for Debian users that speak French. (High-volume mailing list.) Language : French Moderated : no Subscription: open debian-user-german@lists.debian.org Description : Support for Debian users that speak German. (High-volume mailing list.) Language : German Moderated : no Subscription: open debian-user-hungarian Description : Support for Debian users that speak Hungarian. Language : Hungarian Subscription: http://lists.linux.hu/mailman/listinfo/debian debian-user-icelandic@lists.debian.org Description : Support for Debian users that speak Icelandic. Moderated : no Subscription: open debian-user-indonesian@lists.debian.org Description : Support for Debian users who speak Indonesian. Language : Indonesian Moderated : no Subscription: open debian-user-polish@lists.debian.org Description : Support for Debian users that speak Polish. Language : Polish Moderated : no Subscription: open debian-user-portuguese@lists.debian.org Description : Support for Debian users who speak Portuguese. (High-volume mailing list.) Language : Portuguese (both European and Brazilian, and other dialects are welcome) Moderated : no Subscription: open debian-user-spanish@lists.debian.org Description : Support for Debian users that speak Spanish. (High-volume mailing list.) Language : Spanish Moderated : no Subscription: open debian-user-swedish@lists.debian.org Description : Support for Debian users that speak Swedish. Language : Swedish Moderated : no Subscription: open debian-user-turkish@lists.debian.org Description : Support for Debian users that speak Turkish. Language : Turkish Moderated : no Subscription: open debian-user-ukrainian@lists.debian.org Description : Support for Debian users who speak Ukrainian. Language : Ukrainian Moderated : no Subscription: open debian-user-vietnamese@lists.debian.org Description : Support for Debian users that speak Vietnamese, and discussions on translations Language : Vietnamese Moderated : no Subscription: open debian-user@lists.debian.org Description : Support for Debian users who speak English. (High-volume mailing list.) Digest : debian-user-digest@lists.debian.org Moderated : no Subscription: open debian-volatile-announce@lists.debian.org Description : Announcements relating to the debian-volatile project include new uploads and changes Moderated : yes Subscription: open debian-volatile@lists.debian.org Description : Discussion about the debian-volatile archive Moderated : no Subscription: open Development lists There are several lists on which developers and experienced users discuss more technical issues. In addition, there are some announcement lists to help experienced users keep track of development. debian-accessibility@lists.debian.org Description : User and Developer list for accessibility-related issues. Moderated : no Subscription: open debian-admin@lists.debian.org Description : This is our internal list used for administering the Debian machine park. Moderated : no Subscription: closed debian-apache@lists.debian.org Description : Maintenance of the Apache HTTP server and related packages in Debian: code changes, reproducing bugs, talking to upstream etc. It is neither for submitting bug reports (please use the BTS for that), nor for support requests. Moderated : no Subscription: open debian-beowulf@lists.debian.org Description : Discussion about Beowulf systems running Debian. Moderated : no Subscription: open debian-boot@lists.debian.org Description : Discussion and maintenance of the Debian installation system. Moderated : no Subscription: open debian-cd@lists.debian.org Description : Creating Debian CD sets, official and unofficial. Moderated : no Subscription: open debian-ctte-private@lists.debian.org Description : Private communication between tech committee members. Moderated : no Subscription: Debian Technical Committee only debian-ctte@lists.debian.org Description : Public meeting, business and announcements of the Debian Technical Committee Moderated : subscribers Subscription: open debian-custom@lists.debian.org Description : People on this list work on the challenges common to all custom Debian distributions, ensuring that the tools and procedures developed are shared, making the most efficient use of our energies. Moderated : no Subscription: open debian-dak@lists.debian.org Description : Discussion about the Debian Archive Software, consisting of dak for the archive and the buildd related parts wanna-build/sbuild. Moderated : no Subscription: open debian-ddtp@lists.debian.org Description : Discussions on the DDTP and coordination of the development process Moderated : no Subscription: open debian-debbugs-cvs@lists.debian.org Description : CVS commit messages when modifications are done to debbugs Moderated : no Subscription: open debian-debbugs@lists.debian.org Description : Discussion and development of debbugs, the Debian Bug Tracking System software. Moderated : no Subscription: open debian-desktop@lists.debian.org Description : Discussion about the Debian Desktop sub-project, the integration of the various desktop-related packages, bug reports, questions and patches. Moderated : no Subscription: open debian-devel-announce@lists.debian.org Description : Announcements of development issues like policy changes, important release issues &c. Moderated : signed Subscription: open debian-devel-austrian Description : Discussion among the Debian developers in Austria. Language : (mostly) German Subscription: https://www.gibraltar.at/mailman/listinfo/debian-at debian-devel-french@lists.debian.org Description : This is the list used to discuss development issues in French. Moderated : no Subscription: open debian-devel-games@lists.debian.org Description : Development and packaging discussion for games and game-related software in Debian. Identification of potential new games suitable for Debian. Discussion about infrastructure issues covering a wider range of games (e.g. multiplayer issues). Moderated : no Subscription: open debian-devel-italian@lists.debian.org Description : Discussion on development issues in Italian. Moderated : no Subscription: open debian-devel-portuguese@lists.debian.org Description : This is the list used by Portuguese developers (or wannabes) to discuss development issues. Moderated : no Subscription: open debian-devel-spanish@lists.debian.org Description : This is the list used by Spanish developers (or wannabes) to discuss issues besides translation: provide help for new Spanish developers, arrange key-signing meetings, arrange work in booths on different shows, share experience etc. Moderated : no Subscription: open debian-devel@lists.debian.org Description : Discussion about technical development topics. (High-volume mailing list.) Digest : debian-devel-digest@lists.debian.org Moderated : no Subscription: open debian-doc@lists.debian.org Description : Debian Documentation Project: anything related to documentation in Debian is on topic here. Moderated : no Subscription: open debian-dpkg-bugs@lists.debian.org Description : Email sent by the bug tracking system regarding the dpkg packages. Moderated : no Subscription: open debian-dpkg-cvs@lists.debian.org Description : The CVS commit messages from the dpkg CVS tree. Moderated : no Subscription: open debian-dpkg@lists.debian.org Description : Discussions and maintenance of dpkg, the basis of the Debian packaging system. Moderated : no Subscription: open debian-edu-french@lists.debian.org Description : Discussions in french between all educational Debian-based projects. This list should ease the collaboration between the projects themselves and between Debian and those projects. Moderated : no Subscription: open debian-edu@lists.debian.org Description : Making Debian the best distribution in the education landscape. Moderated : no Subscription: open debian-emacsen@lists.debian.org Description : Discussion of all things related to the several Debian Emacs packages and their add-ons. Moderated : no Subscription: open debian-email@lists.debian.org Description : A generic "grab-bag" list for Debian related correspondence such as contacting upstream authors about licenses, bugs etc, or discussing the project with others where it might be useful to have the discussion archived somewhere. This list is archived internally on a Debian Project machine, only developers have access to the archive. Moderated : no Subscription: developers only debian-embedded@lists.debian.org Description : Discussion about improving Debian for use with embedded systems, including building cross-compiler toolchains, cross-compiling packages, creating and updating system images, using alternate libraries, compile-time configuration of packages, etc. Moderated : no Subscription: open debian-events-eu@lists.debian.org Description : Discussions and organizational stuff about booths for Debian at european exhibitions. Moderated : no Subscription: open debian-events-na@lists.debian.org Description : Discussions and organizational stuff about booths and presentations for Debian at North American exhibitions. Moderated : no Subscription: open debian-events-nl@lists.debian.org Description : Announcements of small meetings and keysigning parties of Dutch Debian Developers and other discussions of interest mainly for Debian people in the Netherlands. Posts in both Dutch and English are common. Moderated : no Subscription: open debian-flash@lists.debian.org Description : For discussion of issues relating to the development and use of Debian for Flash development and viewing of Flash content. For general discussion of Flash related free software, please visit the osflash community: http://osflash.org Moderated : no Subscription: open debian-gcc@lists.debian.org Description : Discussion on Debian packaging of GCC, the GNU compiler collection: bug reports, porting issues, any kind of questions or patches. Moderated : no Subscription: open debian-glibc@lists.debian.org Description : Discussion on Debian packaging of the GNU C Library, the most important library on Debian systems. Moderated : no Subscription: open debian-gtk-gnome@lists.debian.org Description : Discussion and coordination among maintainers of Debian's GTK+, GNOME and dependent or related packages. Moderated : no Subscription: open debian-hams@lists.debian.org Description : Support for HAMRadio within Debian GNU/Linux. Moderated : no Subscription: open debian-handheld@lists.debian.org Description : Discussion among people who run Debian on handheld computers. Moderated : no Subscription: open debian-ipv6@lists.debian.org Description : Discussions on the use of Debian in an IPv6 network and implementing IPv6 support in Debian packages. Moderated : no Subscription: open debian-java@lists.debian.org Description : Discussion about the packaging and use in Debian of VMs and compilers for the Java(tm) language, and programs written on it. Moderated : no Subscription: open debian-jr@lists.debian.org Description : Discussion and working on making Debian the sort of operating system that children will want to use. The Debian Jr. Project web page is at http://www.debian.org/devel/debian-jr/ Moderated : no Subscription: open debian-kernel-maint@lists.debian.org Description : Discussion and development of Debian kernel packaging, for the kernel team and other developers. Moderated : no Subscription: open debian-kernel@lists.debian.org Description : Kernels used with Debian (Linux, Hurd, etc.), available patches and flavors, packaging issues, bug reports, porting issues, automated tools, and any other questions or patches that are kernel-related. Mostly bug reporting is done here. Moderated : no Subscription: open debian-knoppix@lists.debian.org Description : Development of the Debian-based live CD/DVD takes place. As it is mainly a development list, user questions are best placed on the debian-user list. Moderated : no Subscription: open debian-lex@lists.debian.org Description : Discussion on developing Debian into an operating system that is particularly well fit for the requirements for legal offices. The goal of Debian-Lex is a complete system for all tasks in legal practice which is built completely on free software. Moderated : no Subscription: open debian-lint-maint@lists.debian.org Description : The maintenance of Debian "lint" tools like lintian or linda is discussed on this list. This may or may not be limited to bug reports regarding the checks. Moderated : no Subscription: open debian-lsb@lists.debian.org Description : Discussion and coordination of efforts towards ensuring Debian meets the requirements of the Linux Standard Base. Moderated : no Subscription: open debian-med@lists.debian.org Description : Discussion on providing a free operating system for medical care. The Debian-Med Project web page is at http://www.debian.org/devel/debian-med/ Moderated : no Subscription: open debian-mentors@lists.debian.org Description : Newbie Debian developers can seek help with packaging and other developer-related issues here. This list is not meant for users' questions, but for new maintainers'! Moderated : no Subscription: open debian-multimedia@lists.debian.org Description : Discussion about the development of applications that produce multimedia content, handling multimedia data, supporting multimedia hardware etc. Moderated : no Subscription: open debian-newmaint@lists.debian.org Description : Discussion about the Debian New Maintainer process, application manager reports etc. Moderated : no Subscription: open debian-nonprofit@lists.debian.org Description : Discussions about the subproject to support use of Debian in non-profit organizations. Moderated : no Subscription: open debian-ocaml-maint@lists.debian.org Description : Packaging of Objective Caml programs and libraries. (http://pauillac.inria.fr/caml/) Moderated : no Subscription: open debian-openoffice@lists.debian.org Description : Coordination of the maintenance of the OpenOffice packages in Debian. Moderated : no Subscription: open debian-perl@lists.debian.org Description : The list is dedicated to coordinate the work of various perl package maintainer and to write a kind of perl sub-policy. Moderated : no Subscription: open debian-policy@lists.debian.org Description : Discussion and editing of the Debian Policy Manual. Moderated : no Subscription: open debian-printing@lists.debian.org Description : Discussion of issues related to printing on Debian systems. This covers all aspects of printing, from spoolers, to RIPs and printer drivers. The list is used for coordination of development, integration and bugfixing of printing packages between package maintainers. User printing and printing setup questions are also on topic. Moderated : no Subscription: open debian-private@lists.debian.org Description : Private discussions among developers: only for issues that may not be discussed on public lists. Anything sent there should be treated as sensitive and not to be spread to other lists; thus cross-posting between it and an open list defeats the purpose of this list. This list is archived internally on a Debian Project machine, only developers have access to the archive. Moderated : no Subscription: developers only debian-python@lists.debian.org Description : Discussion of issues related to Python on Debian systems with a stress on packaging standards. Therefore relevant for maintainers of Python related packages. Moderated : no Subscription: open debian-qa-packages@lists.debian.org Description : Bug reports against orphaned packages and discussions about fixing them. Moderated : no Subscription: open debian-qa@lists.debian.org Description : Quality assurance is important for a distribution. This list addresses this quality. Moderated : no Subscription: open debian-qt-kde@lists.debian.org Description : Discussion and coordination among maintainers of Debian's Qt, KDE and dependent or related packages. Moderated : no Subscription: open debian-release@lists.debian.org Description : Coordination of Debian releases issues such as testing migrations, transitions and removals. This list should not be considered a discussion list; discussions related to releases issues should be held on more appropriate lists such as debian-devel, debian-legal or debian-project. Moderated : no Subscription: open debian-ruby@lists.debian.org Description : Discussion of issues related to Ruby on Debian systems with a stress on packaging standards. Therefore relevant for maintainers of Ruby related packages. Moderated : no Subscription: open debian-science@lists.debian.org Description : Discussion of issues relating to the use of Debian for science research, including useful packages, particular problems faced by scientists using Debian, how to make Debian more useful to scientists, etc. Moderated : no Subscription: open debian-security@lists.debian.org Description : Discussion about security issues, including cryptographic issues, that are of interest to all parts of the Debian community. Please note that this is NOT an announcement mailing list. If you're looking for security advisories from Debian, subscribe to debian-security-announce instead. Moderated : no Subscription: open debian-sgml@lists.debian.org Description : Discussion of issues related to SGML on Debian systems with a stress on proper integration of tools, packaging standards and the writing of documentation for SGML users. Therefore relevant for maintainers of SGML related packages. Moderated : no Subscription: open debian-ssh@lists.debian.org Description : Maintenance of the OpenSSH packages for Debian. It exists to facilitate coordination of ssh maintenance (talking to upstream, reproducing bugs, hacking on the code, etc.). It is *not* the place to mail bug reports (use the BTS for that), nor support requests. Moderated : no Subscription: open debian-testing@lists.debian.org Description : Finding problems with the next Debian release: testing the installation and the upgrade process. Moderated : no Subscription: open debian-tetex-maint@lists.debian.org Description : Coordination of the maintenance of Debian teTeX and related packages. It is not meant for user support; for that, please use debian-user or one of the general TeX mailing lists or news groups. Moderated : no Subscription: open debian-tex-maint@lists.debian.org Description : Coordination of the maintenance of Debian TeX and related packages. It is not meant for user support; for that, please use debian-user or one of the general TeX mailing lists or news groups. Moderated : no Subscription: open debian-toolchain@lists.debian.org Description : Discussion about the Debian toolchain: compilers, assemblers, linkers and such. New releases for many of these tools are coordinated here. Moderated : no Subscription: open debian-vote@lists.debian.org Description : Proposals, discussions and announcements related to Official Debian Votes. Moderated : no Subscription: open debian-webapps@lists.debian.org Description : This list is used to coordinate the maintenance of web application packages. Moderated : no Subscription: open debian-wnpp@lists.debian.org Description : Orphaning and adopting packages which is done through the `wnpp' BTS pseudo-package is recorded on this list. Additionally, discussion about particular bugs and the WNPP web pages is held here. Moderated : no Subscription: open debian-www-cvs@lists.debian.org Description : CVS commit logs for the Debian web pages in the webwml CVS tree. Moderated : yes Subscription: open debian-www@lists.debian.org Description : Design, structure and translation of Debian web pages. All important changes to the web site are announced here as well. Moderated : no Subscription: open debian-x@lists.debian.org Description : Discussion about the X Window System within Debian. This is NOT a user support list; this list is intended for those who deal with the source code. Moderated : no Subscription: open deity@lists.debian.org Description : Debian GNU/Linux will get a new, friendly frontend to its package maintenance system. Its codename is deity (now known as APT) and its development is discussed here. The -digest is open to everyone. Moderated : no Subscription: open Internationalization and Translations These lists cover issues like localization, translation and support for users that don't speak English. debian-i18n@lists.debian.org Description : Internationalization (i18n) of the distribution is discussed here. Moderated : no Subscription: open debian-l10n-arabic@lists.debian.org Description : Discussing Arabic localization issues, mainly translating Debian docs and programs to Arabic. Language : Arabic Moderated : no Subscription: open debian-l10n-catalan@lists.debian.org Description : Discussing Catalan localization issues, mainly translating Debian docs and programs to Catalan. Language : Catalan Moderated : no Subscription: open debian-l10n-czech@lists.debian.org Description : Discussion forum for the translators of Debian-specific packages and documentation to the Czech language. Moderated : no Subscription: open debian-l10n-danish@lists.debian.org Description : Discussing Danish localization issues, mainly translating Debian docs and programs to Danish. Language : Danish Moderated : no Subscription: open debian-l10n-dutch@lists.debian.org Description : Discussion forum for the translators of Debian-specific packages and documentation to the Dutch language. Language : Dutch Moderated : no Subscription: open debian-l10n-english@lists.debian.org Description : Discussing English localization issues, mainly translating Debian docs and programs to English. Language : English Moderated : no Subscription: open debian-l10n-esperanto@lists.debian.org Description : Discussing Esperanto localization issues, mainly translating Debian docs and programs to Esperanto. Language : Esperanto Moderated : no Subscription: open debian-l10n-finnish@lists.debian.org Description : Discussing Finnish localization issues, mainly translating Debian docs and programs to Finnish. Language : Finnish Moderated : no Subscription: open debian-l10n-french@lists.debian.org Description : Discussion forum for the translators of Debian-specific packages and documentation to the French language. Language : French Moderated : no Subscription: open debian-l10n-galician@lists.debian.org Description : Discussing Galician localization issues, mainly translating Debian docs and programs to Galician. Language : Galician Moderated : no Subscription: open debian-l10n-german@lists.debian.org Description : Discussing German localization issues, mainly translating Debian docs and programs to German. Language : German Moderated : no Subscription: open debian-l10n-greek@lists.debian.org Description : Discussion on Greek localization issues, mainly translating Debian docs and programs to Greek. Language : Greek Moderated : no Subscription: open debian-l10n-hungarian@lists.debian.org Description : Discussing Hungarian localization issues, mainly translating Debian docs and programs to Hungarian. Language : Hungarian Moderated : no Subscription: open debian-l10n-italian@lists.debian.org Description : Italian localization efforts within Debian. Language : Italian Moderated : no Subscription: open debian-l10n-korean@lists.debian.org Description : Discussion forum for the translators of Debian-specific packages and documentation to the Korean language. Moderated : no Subscription: open debian-l10n-polish@lists.debian.org Description : Polish localization issues, mainly translating Debian web pages, documentation and programs to Polish. Language : Polish Moderated : no Subscription: open debian-l10n-portuguese@lists.debian.org Description : Portuguese localization issues such as translating the documentation and programs. Language : Portuguese Moderated : no Subscription: open debian-l10n-romanian@lists.debian.org Description : Discussing Romanian localization issues, mainly translating Debian docs and programs to Romanian. Language : Romanian Moderated : no Subscription: open debian-l10n-russian@lists.debian.org Description : Discussing Russian localization issues, mainly translating Debian docs and programs to Russian. Language : Russian Moderated : no Subscription: open debian-l10n-spanish@lists.debian.org Description : Discussing Spanish localization issues, mainly translating Debian docs and programs to Spanish. Language : Spanish Moderated : no Subscription: open debian-l10n-swedish@lists.debian.org Description : Discussion forum for translators of Debian-specific packages and documentation for the Swedish language. Moderated : no Subscription: open debian-l10n-turkish@lists.debian.org Description : Discussing Turkish localization issues, mainly translating Debian docs and website into Turkish, improving Turkish environment support in Debian. Language : Turkish Moderated : no Subscription: open debian-laespiral@lists.debian.org Description : La Espiral (http://laespiral.org/) is a project meant to promote the use of Debian amongst the people who speak Spanish. We work on custom Debian internationalisation CDs, do installation parties and new programs for Spanish users (see http://www.debian.org/international/spanish/). Becoming a member of La Espiral is for people that do not find themselves able to contribute technically to Debian (at first), but might be a good step towards becoming a Debian developer. Language : Spanish Moderated : no Subscription: open Ports to non-i386 Linux architectures and to non-Linux kernels Debian GNU/Linux is ported to several other types of computers, and there are also efforts to create Debian systems on kernels other than Linux. debian-68k@lists.debian.org Description : Discussions on the m68k port of Debian GNU/Linux. Moderated : no Subscription: open debian-alpha@lists.debian.org Description : Discussion on the Alpha port of Debian GNU/Linux. Moderated : no Subscription: open debian-amd64@lists.debian.org Description : Porting Debian to AMD x86-64 architecture. Moderated : no Subscription: open debian-arm@lists.debian.org Description : Discussion on the ARM (esp. Corel Netwinder) port for Debian GNU/Linux. Moderated : no Subscription: open debian-bsd@lists.debian.org Description : Porting Debian to BSD (all *BSD variants). Moderated : no Subscription: open debian-hppa@lists.debian.org Description : Discussions on the PA-RISC port of Debian GNU/Linux. Moderated : no Subscription: open debian-hurd@lists.debian.org Description : Debian port of the GNU Hurd operating system. Moderated : no Subscription: open debian-ia64@lists.debian.org Description : Discussions on the intel IA64 (aka Itanium, Merced) port of Debian GNU/Linux. Moderated : no Subscription: open debian-mips@lists.debian.org Description : Discussions on the MIPS port of Debian GNU/Linux. Moderated : no Subscription: open debian-powerpc@lists.debian.org Description : Discussion on the PowerPC port of Debian GNU/Linux. Moderated : no Subscription: open debian-s390@lists.debian.org Description : Discussions on the IBM S/390 port of Debian GNU/Linux. Moderated : no Subscription: open debian-sparc@lists.debian.org Description : Discussions on the SPARC port of Debian GNU/Linux. Moderated : no Subscription: open debian-superh@lists.debian.org Description : Discussions on the SuperH port of Debian GNU/Linux. For more information about running Linux on SH processors, have a look at http://www.m17n.org/linux-sh/ Moderated : no Subscription: open debian-win32@lists.debian.org Description : Porting the Debian distribution to Win32 systems (Debian GNU/Win32). Moderated : no Subscription: open The Bug Tracking System The Debian bug tracking system is open to the public, and it produces a lot of email. Some of this might be of interest to developers or even users, so it is distributed through these (high-volume) mailing lists. debian-bugs-closed@lists.debian.org Description : Messages that close Debian bug reports. Moderated : no Subscription: open debian-bugs-dist@lists.debian.org Description : All submitted bug reports as well as further information on them are distributed here. Moderated : no Subscription: open debian-bugs-forwarded@lists.debian.org Description : Mails in which Debian maintainers forward bugs to their upstream authors. Moderated : no Subscription: open debian-bugs-rc@lists.debian.org Description : All mail regarding release-critical bugs is copied to this mailing list. See http://bugs.debian.org/release-critical/ for more information. Moderated : no Subscription: open Miscellaneous Debian lists There are several mailing lists which don't necessarily have a clear distinction in the audience, between developers and users. debian-all-changes@lists.debian.org Description : Notices about uploaded binary-all packages for the stable distribution. Moderated : no Subscription: open debian-alpha-changes@lists.debian.org Description : Notices about uploaded packages for the stable alpha distribution, mostly from buildd's. Moderated : no Subscription: open debian-arm-changes@lists.debian.org Description : Notices about uploaded packages for the stable arm distribution, mostly from buildd's. Moderated : no Subscription: open debian-cd-vendors@lists.debian.org Description : Communication among and with vendors of Debian CDs. (Low-volume mailing list.) Moderated : no Subscription: open debian-changes@lists.debian.org Description : Changes to the releases are announced here. This includes security upgrades as well as important bugfixes. Digest : debian-changes-digest@lists.debian.org Moderated : yes Subscription: open debian-consultants@lists.debian.org Description : Communication among Debian consultants. See at the bottom of the consultants page (http://www.debian.org/consultants/#policy) for how to add/update entries to this page. Moderated : no Subscription: open debian-curiosa@lists.debian.org Description : Funny thing from and with the project, funny quotes, discussions irc communication and fortune cookies. Some kind of (de.)alt.netdigest for Debian-related stuff. Moderated : no Subscription: open debian-devel-all-changes@lists.debian.org Description : Notices about uploaded packages for the unstable distribution. (Quiz: binary-all or all binaries?) Moderated : no Subscription: open debian-devel-alpha-changes@lists.debian.org Description : Notices about uploaded packages for the unstable alpha distribution, mostly from buildd's. Moderated : no Subscription: open debian-devel-arm-changes@lists.debian.org Description : Notices about uploaded packages for the unstable arm distribution, mostly from buildd's. Moderated : no Subscription: open debian-devel-changes@lists.debian.org Description : Notices about uploaded packages for the unstable distribution, from developers, buildds and katie, the archive sentinel. (High-volume mailing list.) Moderated : no Subscription: open debian-devel-hurd-i386-changes@lists.debian.org Description : Notices about uploaded packages for the unstable hurd-i386 distribution, mostly from buildd's. Moderated : no Subscription: open debian-devel-i386-changes@lists.debian.org Description : Notices about uploaded packages for the unstable i386 distribution, mostly from buildd's. Moderated : no Subscription: open debian-devel-m68k-changes@lists.debian.org Description : Notices about uploaded packages for the unstable m68k distribution, mostly from buildd's. Moderated : no Subscription: open debian-devel-powerpc-changes@lists.debian.org Description : Notices about uploaded packages for the unstable powerpc distribution, mostly from buildd's. Moderated : no Subscription: open debian-devel-s390-changes@lists.debian.org Description : Notices about uploaded packages for the unstable s390 distribution, mostly from buildd's. Moderated : no Subscription: open debian-devel-sparc-changes@lists.debian.org Description : Notices about uploaded packages for the unstable sparc distribution, mostly from buildd's. Moderated : no Subscription: open debian-hurd-i386-changes@lists.debian.org Description : Notices about uploaded packages for the stable hurd-i386 distribution, mostly from buildd's. Moderated : no Subscription: open debian-i386-changes@lists.debian.org Description : Notices about uploaded packages for the stable i386 distribution, mostly from buildd's. Moderated : no Subscription: open debian-jobs@lists.debian.org Description : Job postings can be published on this list in order to make them public to members of the Debian community. While the jobs do not necessarily have to involve the use of Debian, it is encouraged that they do. Jobs can be about the development of proprietary system, but jobs involving free software (either development or system administration) are preferred. Please include information such as location and remuneration if appropriate. The list is moderated; it is also an open list - job postings which have to be kept private should be sent to leader@debian.org who will distribute them. Moderated : yes Subscription: open debian-legal@lists.debian.org Description : Discussions about legality issues such as copyrights, patents etc. Moderated : no Subscription: open debian-m68k-changes@lists.debian.org Description : Notices about uploaded packages for the stable m68k distribution, mostly from buildd's. Moderated : no Subscription: open debian-mirrors-announce@lists.debian.org Description : Important changes to the FTP archive are announced here. These are mainly useful to maintainers of Debian mirrors. Moderated : signed Subscription: open debian-mirrors@lists.debian.org Description : Discussions relating to the Debian mirror network, and the maintenance of mirrors. Moderated : no Subscription: open debian-powerpc-changes@lists.debian.org Description : Notices about uploaded packages for the stable powerpc distribution, mostly from buildd's. Moderated : no Subscription: open debian-project@lists.debian.org Description : Discussion about non-technical topics related to the Debian Project. Moderated : no Subscription: open debian-publicity@lists.debian.org Description : Coordination of all the work related to the external communication of Debian: drafting new announces, collecting important information that Debian should relay to its community, improving the infrastructure offered to people who want to create Debian booth, etc. Moderated : no Subscription: open debian-s390-changes@lists.debian.org Description : Notices about uploaded packages for the stable s390 distribution, mostly from buildd's. Moderated : no Subscription: open debian-sparc-changes@lists.debian.org Description : Notices about uploaded packages for the stable sparc distribution, mostly from buildd's. Moderated : no Subscription: open debian-testing-changes@lists.debian.org Description : Changes to the "testing" distribution are announced here. This includes various bugfixes. Moderated : no Subscription: open debian-women@lists.debian.org Description : Debian users and developers who wish to involve more women in the Debian project. For discussion and sharing of ideas as well as project collaboration. Moderated : no Subscription: open whitelist@lists.debian.org Description : This is a special pseudo-mailing list to which people can subscribe to prove they are not spammers. This allows one to avoid the restrictions imposed on non-subscriber posts to other mailing lists, in particular the mailing lists that allow posts only from subscribers. Moderated : yes Subscription: open Lists hosted for other projects Our list server provides mailing list facilities for other free projects as well. other-cdwrite@lists.debian.org Description : cdwrite mailing list Moderated : no Subscription: open other-sart@lists.debian.org Description : Discussions and announcements about SART, a free raytracer that uses Guile extension language and is distributed under GPL. The SART website is at http://petra.zesoi.fer.hr/~silovic/sart/ Moderated : no Subscription: open other-vgui-discuss@lists.debian.org Description : The V C++ GUI Framework - an object-oriented GUI library for X, Win32 and OS/2. V is licensed under the GNU LGPL. The web page is at http://www.objectcentral.com/ . Moderated : no Subscription: open Debian mailing list advertising policy -------------------------------------- This policy is intended to fight mailing-list "spamming". The Debian mailing lists accept commercial advertising for payment. The fee for advertisments is a donation of USD 1000 or more to "Software in the Public Interest" (SPI). One donation per advertisement, please. If you prefer to pay in arrears, simply post your advertisement to the list, and the list operator will bill you USD 1999. The list operator will donate this amount, minus the expense of collecting it, to SPI. Please note that the lists are distributed automatically -- messages are generally not read or checked in any way before they are distributed. The act of posting an advertisement indicates your willingness to * accept responsibility for the fee, * indemnify the list operator against any legal claims from you or others in connection with your advertisement, and * pay any legal and business expenses incurred in collecting late payment. Our liability to you is limited to a good-faith effort to deliver your message. Reduced rates and/or waiver of fee are available for Debian-related advertisements. You must consult the list operator in advance of posting for any reduction or fee waiver. -- Online HTML version of this document is available at http://www.debian.org/MailingLists/subscribe doc-debian-6.1/doc/social-contract.1.0.wml0000664000000000000000000001664012037617006015116 0ustar

Version 1.0 ratified on July 5, 1997. Superseded by Version 1.1, ratified on April 26, 2004.

Debian, the producers of the Debian GNU/Linux system, have created the Debian Social Contract. The Debian Free Software Guidelines (DFSG) part of the contract, initially designed as a set of commitments that we agree to abide by, has been adopted by the free software community as the basis of the Open Source Definition.

"Social Contract" with the Free Software Community

  1. Debian Will Remain 100% Free Software

    We promise to keep the Debian GNU/Linux Distribution entirely free software. As there are many definitions of free software, we include the guidelines we use to determine if software is "free" below. We will support our users who develop and run non-free software on Debian, but we will never make the system depend on an item of non-free software.

  2. We Will Give Back to the Free Software Community

    When we write new components of the Debian system, we will license them as free software. We will make the best system we can, so that free software will be widely distributed and used. We will feed back bug-fixes, improvements, user requests, etc. to the "upstream" authors of software included in our system.

  3. We Won't Hide Problems

    We will keep our entire bug-report database open for public view at all times. Reports that users file on-line will immediately become visible to others.

  4. Our Priorities are Our Users and Free Software

    We will be guided by the needs of our users and the free-software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environment. We won't object to commercial software that is intended to run on Debian systems, and we'll allow others to create value-added distributions containing both Debian and commercial software, without any fee from us. To support these goals, we will provide an integrated system of high-quality, 100% free software, with no legal restrictions that would prevent these kinds of use.

  5. Programs That Don't Meet Our Free-Software Standards

    We acknowledge that some of our users require the use of programs that don't conform to the Debian Free Software Guidelines. We have created "contrib" and "non-free" areas in our FTP archive for this software. The software in these directories is not part of the Debian system, although it has been configured for use with Debian. We encourage CD manufacturers to read the licenses of software packages in these directories and determine if they can distribute that software on their CDs. Thus, although non-free software isn't a part of Debian, we support its use, and we provide infrastructure (such as our bug-tracking system and mailing lists) for non-free software packages.

The Debian Free Software Guidelines (DFSG)

  1. Free Redistribution

    The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale.

  2. Source Code

    The program must include source code, and must allow distribution in source code as well as compiled form.

  3. Derived Works

    The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

  4. Integrity of The Author's Source Code

    The license may restrict source-code from being distributed in modified form _only_ if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. (This is a compromise. The Debian group encourages all authors not to restrict any files, source or binary, from being modified.)

  5. No Discrimination Against Persons or Groups

    The license must not discriminate against any person or group of persons.

  6. No Discrimination Against Fields of Endeavor

    The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

  7. Distribution of License

    The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

  8. License Must Not Be Specific to Debian

    The rights attached to the program must not depend on the program's being part of a Debian system. If the program is extracted from Debian and used or distributed without Debian but otherwise within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the Debian system.

  9. License Must Not Contaminate Other Software

    The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be free software.

  10. Example Licenses

    The "GPL", "BSD", and "Artistic" licenses are examples of licenses that we consider "free".

The concept of stating our "social contract with the free software community" was suggested by Ean Schuessler. This document was drafted by Bruce Perens, refined by the other Debian developers during a month-long e-mail conference in June 1997, and then \ accepted as the publicly stated policy of the Debian Project.

Bruce Perens later removed the Debian-specific references from the Debian Free Software Guidelines to create “The Open Source Definition”.

Other organizations may derive from and build on this document. Please give credit to the Debian project if you do. doc-debian-6.1/doc/bug-reporting.wml0000664000000000000000000004404112037617006014314 0ustar

How to report a bug in Debian using reportbug

We strongly recommend that you report bugs in Debian using the reportbug program. To install and start it, simply run:

# aptitude install reportbug
$ reportbug

It will guide you through the bug reporting process step by step.

If you have questions that the interactive prompts of reportbug do not resolve, you can refer to the rest of the documentation below or ask the Debian user mailing list.

How to report a bug in Debian using email (and advanced usage of reportbug)

Important things to note before sending your bug report

What package does your bug report belong to?

You need to know what package your bug report should be filed against. See this example for information on how to find this information. (You will use this information to see if your bug report has been filed already.)

If you are unable to determine which package your bug report should be filed against, please send e-mail to the Debian user mailing list asking for advice.

If your problem doesn't relate just to one package but some general Debian service, there are several pseudo-packages or even mailing lists that you can use to relay your message to us instead.

Has your bug report been filed already?

You should check to see if your bug report has already been filed before submitting it. You can see which bugs have been filed in a specific package using the package option of the bug search form. If there is an existing bug report #<number>, you should submit your comments by sending e-mail to <number>@bugs.debian.org instead of reporting a new bug.

Send multiple reports for multiple bugs

Please don't report multiple unrelated bugs — especially ones in different packages — in a single bug report.

Don't file bugs upstream

If you file a bug in Debian, don't send a copy to the upstream software maintainers yourself, as it is possible that the bug exists only in Debian. If necessary, the maintainer of the package will forward the bug upstream.

Sending the bug report via e-mail

You can report bugs in Debian by sending an e-mail to submit@bugs.debian.org with a special format described below. reportbug (see above) will properly format the e-mails for you; please use it!

Headers

Like any e-mail you should include a clear, descriptive Subject line in your main mail header. The subject you give will be used as the initial bug title in the tracking system, so please try to make it informative!

If you'd like to send a copy of your bug report to additional recipients (such as mailing lists), you shouldn't use the usual e-mail headers, but a different method, described below.

Pseudo-headers

The first part of the bug report are the pseudo-headers which contain information about what package and version your bug report applies to. The first line of the message body has to include a pseudo-header. It should say:

Package: <packagename>

Replace <packagename> with the name of the package which has the bug.

The second line of the message should say:

Version: <packageversion>

Replace <packageversion> with the version of the package. Please don't include any text here other than the version itself, as the bug tracking system relies on this field to work out which releases are affected by the bug.

You need to supply a correct Package line in the pseudo-header in order for the bug tracking system to deliver the message to the package's maintainer. See this example for information on how to find this information.

For other valid pseudo-headers, see Additional pseudo-headers

The body of the report

Please include in your report:

Include any detail that seems relevant — you are in very little danger of making your report too long by including too much information. If they are small, please include in your report any files you were using to reproduce the problem. (If they are large, consider making them available on a publicly available website if possible.)

For more advice on how to help the developers solve your problem, please read How to Report Bugs Effectively.

An Example Bug Report

A bug report with header and pseudo-header looks something like this:

  To: submit@bugs.debian.org
  From: diligent@testing.linux.org
  Subject: Hello says `goodbye'

  Package: hello
  Version: 1.3-16

  When I invoke `hello' without arguments from an ordinary shell
  prompt it prints `goodbye', rather than the expected `hello, world'.
  Here is a transcript:

  $ hello
  goodbye
  $ /usr/bin/hello
  goodbye
  $

  I suggest that the output string, in hello.c, be corrected.

  I am using Debian GNU/Linux 2.2, kernel 2.2.17-pre-patch-13
  and libc6 2.1.3-10.

Sending copies of bug reports to other addresses

Sometimes it is necessary to send a copy of a bug report to somewhere else besides debian-bugs-dist and the package maintainer, which is where they are normally sent.

You could do this by CC'ing your bug report to the other address(es), but then the other copies would not have the bug report number put in the Reply-To field and the Subject line. When the recipients reply they will probably preserve the submit@bugs.debian.org entry in the header and have their message filed as a new bug report. This leads to many duplicated reports.

The right way to do this is to use the X-Debbugs-CC header. Add a line like this to your message's mail header:

 X-Debbugs-CC: other-list@cosmic.edu

This will cause the bug tracking system to send a copy of your report to the address(es) in the X-Debbugs-CC line as well as to debian-bugs-dist.

Avoid sending such copies to the addresses of other bug reports, as they will be caught by the checks that prevent mail loops. There is relatively little point in using X-Debbugs-CC for this anyway, as the bug number added by that mechanism will just be replaced by a new one; use an ordinary CC header instead.

This feature can often be combined usefully with mailing quiet — see below.

Additional Pseudoheaders

Severity levels

If a report is of a particularly serious bug, or is merely a feature request, you can set the severity level of the bug as you report it. This is not required however, and the package maintainer will assign an appropriate severity level to your report even if you do not (or pick the wrong severity).

To assign a severity level, put a line like this one in the pseudo-header:

Severity: <severity>

Replace <severity> with one of the available severity levels, as described in the advanced documentation.

Assigning tags

You can set tags on a bug as you are reporting it. For example, if you are including a patch with your bug report, you may wish to set the patch tag. This is not required, however, and the developers will set tags on your report as and when it is appropriate.

To set tags, put a line like this one in the pseudo-header:

Tags: <tags>

Replace <tags> with one or more of the available tags, as described in the advanced documentation. Separate multiple tags with commas, spaces, or both.

User: <username>
Usertags: <usertags>

Replace <usertags> with one or more usertags. Separate multiple tags with commas, spaces, or both. If you specify a <username>, that user's tags will be set. Otherwise, the e-mail address of the sender will be used as the username.

Setting Forwarded

Forwarded: foo@example.com

will mark the newly submitted bug as forwarded to foo@example.com. See Recording that you have passed on a bug report in the developers' documentation for details.

Claiming ownership

Owner: foo@example.com

will indicate that foo@example.com is now responsible for fixing this bug. See Changing bug ownership in the developers' documentation for details.

Source Package

Source: foopackage

the equivalent of Package: for bugs present in the source package of foopackage; for most bugs in most packages you don't want to use this option.

Control Commands

Control: control commands

Allows for any of the commands which must be sent to control@bugs.debian.org to work when sent to submit@bugs.debian.org or nnn@bugs.debian.org. Please see the server control documentation for more information on the control commands which are valid.

X-Debbugs- headers

Finally, if your MUA doesn't allow you to edit the headers, you can set the various X-Debbugs- headers in the pseudo-headers.

Additional information

Different submission addresses (minor or mass bug reports)

If a bug report is minor, for example, a documentation typo or a trivial build problem, please adjust the severity appropriately and send it to maintonly@bugs.debian.org instead of submit@bugs.debian.org. maintonly will forward the report to the package maintainer only, it won't forward it to the BTS mailing lists.

If you're submitting many reports at once, you should definitely use maintonly@bugs.debian.org so that you don't cause too much redundant traffic on the BTS mailing lists. Before submitting many similar bugs you may also want to post a summary on debian-bugs-dist.

If wish to report a bug to the bug tracking system that's already been sent to the maintainer, you can use quiet@bugs.debian.org. Bugs sent to quiet@bugs.debian.org will not be forwarded anywhere, only filed.

When you use different submission addresses, the bug tracking system will set the Reply-To of any forwarded message so that the replies will by default be processed in the same way as the original report. That means that, for example, replies to maintonly will go to nnn-maintonly@bugs.debian.org instead of nnn@bugs.debian.org, unless of course one overrides this manually.

Acknowledgements

Normally, the bug tracking system will return an acknowledgement to you by e-mail when you report a new bug or submit additional information to an existing bug. If you want to suppress this acknowledgement, include an X-Debbugs-No-Ack header or pseudoheader in your e-mail (the contents of this header do not matter). If you report a new bug with this header, you will need to check the web interface yourself to find the bug number.

Note that this header will not suppress acknowledgements from the control@bugs.debian.org mailserver, since those acknowledgements may contain error messages which should be read and acted upon.

Spamfighting and missing mail

The bug tracking system implements a rather extensive set of rules designed to make sure that spam does not make it through the BTS. While we try to minimize the number of false positives, they do occur. If you suspect your mail has triggered a false positive, feel free to contact owner@bugs.debian.org for assistance. Another common cause of mail not making it through to the BTS is utilizing addresses which match procmail's FROM_DAEMON, which includes mail from addresses like mail@foobar.com. If you suspect your mail matches FROM_DAEMON, see procmailrc(5) to verify, and then resend the mail using an address which does not match FROM_DAEMON.

Bug reports against unknown packages

If the bug tracking system doesn't know who the maintainer of the relevant package is it will forward the report to debian-bugs-dist even if maintonly was used.

When sending to maintonly@bugs.debian.org or nnn-maintonly@bugs.debian.org you should make sure that the bug report is assigned to the right package, by putting a correct Package at the top of an original submission of a report, or by using the control@bugs.debian.org service to (re)assign the report appropriately.

Using dpkg to find the package and version for the report

When using reportbug to report a bug in a command, say grep, the following will automatically select the right package and let you write the report right away: reportbug --file $(which grep)

You can also find out which package installed it by using dpkg --search. You can find out which version of a package you have installed by using dpkg --list or dpkg --status.

For example:

$ which apt-get
/usr/bin/apt-get
$ type apt-get
apt-get is /usr/bin/apt-get
$ dpkg --search /usr/bin/apt-get
apt: /usr/bin/apt-get
$ dpkg --list apt
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  apt            0.3.19         Advanced front-end for dpkg
$ dpkg --status apt
Package: apt
Status: install ok installed
Priority: standard
Section: base
Installed-Size: 1391
Maintainer: APT Development Team <deity@lists.debian.org>
Version: 0.3.19
Replaces: deity, libapt-pkg-doc (<< 0.3.7), libapt-pkg-dev (<< 0.3.7)
Provides: libapt-pkg2.7
Depends: libapt-pkg2.7, libc6 (>= 2.1.2), libstdc++2.10
Suggests: dpkg-dev
Conflicts: deity
Description: Advanced front-end for dpkg
 This is Debian's next generation front-end for the dpkg package manager.
 It provides the apt-get utility and APT dselect method that provides a
 simpler, safer way to install and upgrade packages.
 .
 APT features complete installation ordering, multiple source capability
 and several other unique features, see the Users Guide in
 /usr/doc/apt/guide.text.gz

Other useful commands and packages

The querybts tool, available from the same package as reportbug, provides a convenient text-based interface to the bug tracking system.

Emacs users can also use the debian-bug command provided by the \ debian-el package. When called with M-x debian-bug, it will ask for all necessary information in a similar way to reportbug.

doc-debian-6.1/doc/constitution.1.3.wml0000664000000000000000000010253712037617006014577 0ustar

Historical version of the Constitution for the Debian Project (v1.3)

Version 1.3 ratified on September 24th, 2006. Supersedes Version 1.2 ratified on October 29th, 2003 and Version 1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 ratified on December 2nd, 1998. That was superseded by the current version, 1.4 ratified on October 7th, 2007.

1. Introduction

The Debian Project is an association of individuals who have made common cause to create a free operating system.

This document describes the organisational structure for formal decision-making in the Project. It does not describe the goals of the Project or how it achieves them, or contain any policies except those directly related to the decision-making process.

2. Decision-making bodies and individuals

Each decision in the Project is made by one or more of the following:

  1. The Developers, by way of General Resolution or an election;
  2. The Project Leader;
  3. The Technical Committee and/or its Chairman;
  4. The individual Developer working on a particular task;
  5. Delegates appointed by the Project Leader for specific tasks;
  6. The Project Secretary.

Most of the remainder of this document will outline the powers of these bodies, their composition and appointment, and the procedure for their decision-making. The powers of a person or body may be subject to review and/or limitation by others; in this case the reviewing body or person's entry will state this. In the list above, a person or body is usually listed before any people or bodies whose decisions they can overrule or who they (help) appoint - but not everyone listed earlier can overrule everyone listed later.

2.1. General rules

  1. Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them.

  2. A person may hold several posts, except that the Project Leader, Project Secretary and the Chairman of the Technical Committee must be distinct, and that the Leader cannot appoint themselves as their own Delegate.

  3. A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly.

3. Individual Developers

3.1. Powers

An individual Developer may

  1. make any technical or nontechnical decision with regard to their own work;
  2. propose or sponsor draft General Resolutions;
  3. propose themselves as a Project Leader candidate in elections;
  4. vote on General Resolutions and in Leadership elections.

3.2. Composition and appointment

  1. Developers are volunteers who agree to further the aims of the Project insofar as they participate in it, and who maintain package(s) for the Project or do other work which the Project Leader's Delegate(s) consider worthwhile.

  2. The Project Leader's Delegate(s) may choose not to admit new Developers, or expel existing Developers. If the Developers feel that the Delegates are abusing their authority they can of course override the decision by way of General Resolution - see §4.1(3), §4.2.

3.3. Procedure

Developers may make these decisions as they see fit.

4. The Developers by way of General Resolution or election

4.1. Powers

Together, the Developers may:

  1. Appoint or recall the Project Leader.

  2. Amend this constitution, provided they agree with a 3:1 majority.

  3. Make or override any decision authorised by the powers of the Project Leader or a Delegate.

  4. Make or override any decision authorised by the powers of the Technical Committee, provided they agree with a 2:1 majority.

  5. Issue, supersede and withdraw nontechnical policy documents and statements.

    These include documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software licence terms that Debian software must meet.

    They may also include position statements about issues of the day.

    1. A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes.
    2. The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines.
    3. A Foundation Document requires a 3:1 majority for its supersession. New Foundation Documents are issued and existing ones withdrawn by amending the list of Foundation Documents in this constitution.

  6. Make decisions about property held in trust for purposes related to Debian. (See §9.).

  7. In case of a disagreement between the project leader and the incumbent secretary, appoint a new secretary.

4.2. Procedure

  1. The Developers follow the Standard Resolution Procedure, below. A resolution or amendment is introduced if proposed by any Developer and sponsored by at least K other Developers, or if proposed by the Project Leader or the Technical Committee.

  2. Delaying a decision by the Project Leader or their Delegate:

    1. If the Project Leader or their Delegate, or the Technical Committee, has made a decision, then Developers can override them by passing a resolution to do so; see §4.1(3).
    2. If such a resolution is sponsored by at least 2K Developers, or if it is proposed by the Technical Committee, the resolution puts the decision immediately on hold (provided that resolution itself says so).
    3. If the original decision was to change a discussion period or a voting period, or the resolution is to override the Technical Committee, then only K Developers need to sponsor the resolution to be able to put the decision immediately on hold.
    4. If the decision is put on hold, an immediate vote is held to determine whether the decision will stand until the full vote on the decision is made or whether the implementation of the original decision will be delayed until then. There is no quorum for this immediate procedural vote.
    5. If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted.

  3. Votes are taken by the Project Secretary. Votes, tallies, and results are not revealed during the voting period; after the vote the Project Secretary lists all the votes cast. The voting period is 2 weeks, but may be varied by up to 1 week by the Project Leader.

  4. The minimum discussion period is 2 weeks, but may be varied by up to 1 week by the Project Leader. The Project Leader has a casting vote. There is a quorum of 3Q.

  5. Proposals, sponsors, amendments, calls for votes and other formal actions are made by announcement on a publicly-readable electronic mailing list designated by the Project Leader's Delegate(s); any Developer may post there.

  6. Votes are cast by email in a manner suitable to the Secretary. The Secretary determines for each poll whether voters can change their votes.

  7. Q is half of the square root of the number of current Developers. K is Q or 5, whichever is the smaller. Q and K need not be integers and are not rounded.

5. Project Leader

5.1. Powers

The Project Leader may:

  1. Appoint Delegates or delegate decisions to the Technical Committee.

    The Leader may define an area of ongoing responsibility or a specific decision and hand it over to another Developer or to the Technical Committee.

    Once a particular decision has been delegated and made the Project Leader may not withdraw that delegation; however, they may withdraw an ongoing delegation of particular area of responsibility.

  2. Lend authority to other Developers.

    The Project Leader may make statements of support for points of view or for other members of the project, when asked or otherwise; these statements have force if and only if the Leader would be empowered to make the decision in question.

  3. Make any decision which requires urgent action.

    This does not apply to decisions which have only become gradually urgent through lack of relevant action, unless there is a fixed deadline.

  4. Make any decision for whom noone else has responsibility.

  5. Propose draft General Resolutions and amendments.

  6. Together with the Technical Committee, appoint new members to the Committee. (See §6.2.)

  7. Use a casting vote when Developers vote.

    The Project Leader also has a normal vote in such ballots.

  8. Vary the discussion period for Developers' votes (as above).

  9. Lead discussions amongst Developers.

    The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand. The Project Leader should not use the Leadership position to promote their own personal views.

  10. In consultation with the developers, make decisions affecting property held in trust for purposes related to Debian. (See §9.). Such decisions are communicated to the members by the Project Leader or their Delegate(s). Major expenditures should be proposed and debated on the mailing list before funds are disbursed.

  11. Add or remove organizations from the list of trusted organizations (see §9.3) that are authorized to accept and hold assets for Debian. The evaluation and discussion leading up to such a decision occurs on an electronic mailing list designated by the Project Leader or their Delegate(s), on which any developer may post. There is a minimum discussion period of two weeks before an organization may be added to the list of trusted organizations.

5.2. Appointment

  1. The Project Leader is elected by the Developers.
  2. The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately.
  3. For the following three weeks any Developer may nominate themselves as a candidate Project Leader.
  4. For three weeks after that no more candidates may be nominated; candidates should use this time for campaigning (to make their identities and positions known). If there are no candidates at the end of the nomination period then the nomination period is extended for three further weeks, repeatedly if necessary.
  5. The next three weeks are the polling period during which Developers may cast their votes. Votes in leadership elections are kept secret, even after the election is finished.
  6. The options on the ballot will be those candidates who have nominated themselves and have not yet withdrawn, plus None Of The Above. If None Of The Above wins the election then the election procedure is repeated, many times if necessary.
  7. The decision will be made using the method specified in section §A.6 of the Standard Resolution Procedure. The quorum is the same as for a General Resolution (§4.2) and the default option is None Of The Above.
  8. The Project Leader serves for one year from their election.

5.3. Procedure

The Project Leader should attempt to make decisions which are consistent with the consensus of the opinions of the Developers.

Where practical the Project Leader should informally solicit the views of the Developers.

The Project Leader should avoid overemphasizing their own point of view when making decisions in their capacity as Leader.

6. Technical committee

6.1. Powers

The Technical Committee may:

  1. Decide on any matter of technical policy.

    This includes the contents of the technical policy manuals, developers' reference materials, example packages and the behaviour of non-experimental package building tools. (In each case the usual maintainer of the relevant software or documentation makes decisions initially, however; see 6.3(5).)

  2. Decide any technical matter where Developers' jurisdictions overlap.

    In cases where Developers need to implement compatible technical policies or stances (for example, if they disagree about the priorities of conflicting packages, or about ownership of a command name, or about which package is responsible for a bug that both maintainers agree is a bug, or about who should be the maintainer for a package) the technical committee may decide the matter.

  3. Make a decision when asked to do so.

    Any person or body may delegate a decision of their own to the Technical Committee, or seek advice from it.

  4. Overrule a Developer (requires a 3:1 majority).

    The Technical Committee may ask a Developer to take a particular technical course of action even if the Developer does not wish to; this requires a 3:1 majority. For example, the Committee may determine that a complaint made by the submitter of a bug is justified and that the submitter's proposed solution should be implemented.

  5. Offer advice.

    The Technical Committee may make formal announcements about its views on any matter. Individual members may of course make informal statements about their views and about the likely views of the committee.

  6. Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.)

  7. Appoint the Chairman of the Technical Committee.

    The Chairman is elected by the Committee from its members. All members of the committee are automatically nominated; the committee votes starting one week before the post will become vacant (or immediately, if it is already too late). The members may vote by public acclamation for any fellow committee member, including themselves; there is no default option. The vote finishes when all the members have voted, or when the voting period has ended. The result is determined using the method specified in section A.6 of the Standard Resolution Procedure.

  8. The Chairman can stand in for the Leader, together with the Secretary

    As detailed in §7.1(2), the Chairman of the Technical Committee and the Project Secretary may together stand in for the Leader if there is no Leader.

6.2. Composition

  1. The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members.

  2. When there are fewer than 8 members the Technical Committee may recommend new member(s) to the Project Leader, who may choose (individually) to appoint them or not.

  3. When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6.

  4. When there have been 5 members or fewer for at least one week the Project Leader may appoint new member(s) until the number of members reaches 6, at intervals of at least one week per appointment.

  5. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee.

6.3. Procedure

  1. The Technical Committee uses the Standard Resolution Procedure.

    A draft resolution or amendment may be proposed by any member of the Technical Committee. There is no minimum discussion period; the voting period lasts for up to one week, or until the outcome is no longer in doubt. Members may change their votes. There is a quorum of two.

  2. Details regarding voting

    The Chairman has a casting vote. When the Technical Committee votes whether to override a Developer who also happens to be a member of the Committee, that member may not vote (unless they are the Chairman, in which case they may use only their casting vote).

  3. Public discussion and decision-making.

    Discussion, draft resolutions and amendments, and votes by members of the committee, are made public on the Technical Committee public discussion list. There is no separate secretary for the Committee.

  4. Confidentiality of appointments.

    The Technical Committee may hold confidential discussions via private email or a private mailing list or other means to discuss appointments to the Committee. However, votes on appointments must be public.

  5. No detailed design work.

    The Technical Committee does not engage in design of new proposals and policies. Such design work should be carried out by individuals privately or together and discussed in ordinary technical policy and design forums.

    The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere.

    Individual members of the technical committee may of course participate on their own behalf in any aspect of design and policy work.

  6. Technical Committee makes decisions only as last resort.

    The Technical Committee does not make a technical decision until efforts to resolve it via consensus have been tried and failed, unless it has been asked to make a decision by the person or body who would normally be responsible for it.

7. The Project Secretary

7.1. Powers

The Secretary:

  1. Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution.

  2. Can stand in for the Leader, together with the Chairman of the Technical Committee.

    If there is no Project Leader then the Chairman of the Technical Committee and the Project Secretary may by joint agreement make decisions if they consider it imperative to do so.

  3. Adjudicates any disputes about interpretation of the constitution.

  4. May delegate part or all of their authority to someone else, or withdraw such a delegation at any time.

7.2. Appointment

The Project Secretary is appointed by the Project Leader and the current Project Secretary.

If the Project Leader and the current Project Secretary cannot agree on a new appointment, they must ask the Developers by way of General Resolution to appoint a Secretary.

If there is no Project Secretary or the current Secretary is unavailable and has not delegated authority for a decision then the decision may be made or delegated by the Chairman of the Technical Committee, as Acting Secretary.

The Project Secretary's term of office is 1 year, at which point they or another Secretary must be (re)appointed.

7.3. Procedure

The Project Secretary should make decisions which are fair and reasonable, and preferably consistent with the consensus of the Developers.

When acting together to stand in for an absent Project Leader the Chairman of the Technical Committee and the Project Secretary should make decisions only when absolutely necessary and only when consistent with the consensus of the Developers.

8. The Project Leader's Delegates

8.1. Powers

The Project Leader's Delegates:

  1. have powers delegated to them by the Project Leader;
  2. may make certain decisions which the Leader may not make directly, including approving or expelling Developers or designating people as Developers who do not maintain packages. This is to avoid concentration of power, particularly over membership as a Developer, in the hands of the Project Leader.

8.2. Appointment

The Delegates are appointed by the Project Leader and may be replaced by the Leader at the Leader's discretion. The Project Leader may not make the position as a Delegate conditional on particular decisions by the Delegate, nor may they override a decision made by a Delegate once made.

8.3. Procedure

Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion.

9. Assets held in trust for Debian

In most jurisdictions around the world, the Debian project is not in a position to directly hold funds or other property. Therefore, property has to be owned by any of a number of organisations as detailed in §9.2.

Traditionally, SPI was the sole organisation authorized to hold property and monies for the Debian Project. SPI was created in the U.S. to hold money in trust there.

SPI and Debian are separate organisations who share some goals. Debian is grateful for the legal support framework offered by SPI.

9.1. Relationship with Associated Organizations

  1. Debian Developers do not become agents or employees of organisations holding assets in trust for Debian, or of each other, or of persons in authority in the Debian Project, solely by the virtue of being Debian Developers. A person acting as a Developer does so as an individual, on their own behalf. Such organisations may, of their own accord, establish relationships with individuals who are also Debian developers.

9.2. Authority

  1. An organisation holding assets for Debian has no authority regarding Debian's technical or nontechnical decisions, except that no decision by Debian with respect to any property held by the organisation shall require it to act outside its legal authority.

  2. Debian claims no authority over an organisation that holds assets for Debian other than that over the use of property held in trust for Debian.

9.3. Trusted organisations

Any donations for the Debian Project must be made to any one of a set of organisations designated by the Project leader (or a delegate) to be authorized to handle assets to be used for the Debian Project.

Organisations holding assets in trust for Debian should undertake reasonable obligations for the handling of such assets.

Debian maintains a public List of Trusted Organisations that accept donations and hold assets in trust for Debian (including both tangible property and intellectual property) that includes the commitments those organisations have made as to how those assets will be handled.

A. Standard Resolution Procedure

These rules apply to communal decision-making by committees and plebiscites, where stated above.

A.1. Proposal

The formal procedure begins when a draft resolution is proposed and sponsored, as required.

A.1. Discussion and Amendment

  1. Following the proposal, the resolution may be discussed. Amendments may be made formal by being proposed and sponsored according to the requirements for a new resolution, or directly by the proposer of the original resolution.
  2. A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match.
  3. If a formal amendment is not accepted, or one of the sponsors of the resolution does not agree with the acceptance by the proposer of a formal amendment, the amendment remains as an amendment and will be voted on.
  4. If an amendment accepted by the original proposer is not to the liking of others, they may propose another amendment to reverse the earlier change (again, they must meet the requirements for proposer and sponsor(s).)
  5. The proposer of a resolution may suggest changes to the wordings of amendments; these take effect if the proposer of the amendment agrees and none of the sponsors object. In this case the changed amendments will be voted on instead of the originals.
  6. The proposer of a resolution may make changes to correct minor errors (for example, typographical errors or inconsistencies) or changes which do not alter the meaning, providing noone objects within 24 hours. In this case the minimum discussion period is not restarted.

A.2. Calling for a vote

  1. The proposer or a sponsor of a motion or an amendment may call for a vote, providing that the minimum discussion period (if any) has elapsed.
  2. The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments.
  3. The person who calls for a vote states what they believe the wordings of the resolution and any relevant amendments are, and consequently what form the ballot should take. However, the final decision on the form of ballot(s) is the Secretary's - see 7.1(1), 7.1(3) and A.3(4).
  4. The minimum discussion period is counted from the time the last formal amendment was accepted, or since the whole resolution was proposed if no amendments have been proposed and accepted.

A.3. Voting procedure

  1. Each resolution and its related amendments is voted on in a single ballot that includes an option for the original resolution, each amendment, and the default option (where applicable).
  2. The default option must not have any supermajority requirements. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement.
  3. The votes are counted according to the rules in A.6. The default option is Further Discussion, unless specified otherwise.
  4. In cases of doubt the Project Secretary shall decide on matters of procedure.

A.4. Withdrawing resolutions or unaccepted amendments

The proposer of a resolution or unaccepted amendment may withdraw it. In this case new proposers may come forward keep it alive, in which case the first person to do so becomes the new proposer and any others become sponsors if they aren't sponsors already.

A sponsor of a resolution or amendment (unless it has been accepted) may withdraw.

If the withdrawal of the proposer and/or sponsors means that a resolution has no proposer or not enough sponsors it will not be voted on unless this is rectified before the resolution expires.

A.5. Expiry

If a proposed resolution has not been discussed, amended, voted on or otherwise dealt with for 4 weeks the secretary may issue a statement that the issue is being withdrawn. If none of the sponsors of any of the proposals object within a week, the issue is withdrawn.

The secretary may also include suggestions on how to proceed, if appropriate.

A.6. Vote Counting

  1. Each voter's ballot ranks the options being voted on. Not all options need be ranked. Ranked options are considered preferred to all unranked options. Voters may rank options equally. Unranked options are considered to be ranked equally with one another. Details of how ballots may be filled out will be included in the Call For Votes.
  2. If the ballot has a quorum requirement R any options other than the default option which do not receive at least R votes ranking that option above the default option are dropped from consideration.
  3. Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration.
    1. Given two options A and B, V(A,B) is the number of voters who prefer option A over option B.
    2. An option A defeats the default option D by a majority ratio N, if V(A,D) is strictly greater than N * V(D,A).
    3. If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1.
  4. From the list of undropped options, we generate a list of pairwise defeats.
    1. An option A defeats an option B, if V(A,B) is strictly greater than V(B,A).
  5. From the list of [undropped] pairwise defeats, we generate a set of transitive defeats.
    1. An option A transitively defeats an option C if A defeats C or if there is some other option B where A defeats B AND B transitively defeats C.
  6. We construct the Schwartz set from the set of transitive defeats.
    1. An option A is in the Schwartz set if for all options B, either A transitively defeats B, or B does not transitively defeat A.
  7. If there are defeats between options in the Schwartz set, we drop the weakest such defeats from the list of pairwise defeats, and return to step 5.
    1. A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) is less than V(B,Y). Also, (A,X) is weaker than (B,Y) if V(A,X) is equal to V(B,Y) and V(X,A) is greater than V(Y,B).
    2. A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat.
  8. If there are no defeats within the Schwartz set, then the winner is chosen from the options in the Schwartz set. If there is only one such option, it is the winner. If there are multiple options, the elector with the casting vote chooses which of those options wins.

Note: Options which the voters rank above the default option are options they find acceptable. Options ranked below the default options are options they find unacceptable.

When the Standard Resolution Procedure is to be used, the text which refers to it must specify what is sufficient to have a draft resolution proposed and/or sponsored, what the minimum discussion period is, and what the voting period is. It must also specify any supermajority and/or the quorum (and default option) to be used.

B. Use of language and typography

The present indicative (is, for example) means that the statement is a rule in this constitution. May or can indicates that the person or body has discretion. Should means that it would be considered a good thing if the sentence were obeyed, but it is not binding. Text marked as a citation, such as this, is rationale and does not form part of the constitution. It may be used only to aid interpretation in cases of doubt.

doc-debian-6.1/doc/bug-maint-mailcontrol.wml0000664000000000000000000006204712037617006015742 0ustar

Introduction to the bug control and manipulation mailserver

Just as request@bugs.debian.org allows the retrieval of bug data and documentation by email, control@bugs.debian.org allows bug reports to be manipulated in various ways.

The control server works just like the request server, except that it has some additional commands; in fact, it's the same program. The two addresses are only separated to avoid users making mistakes and causing problems while merely trying to request information.

Since the commands specific to the control server actually change the status of a bug, a notification about processing the commands is sent to the maintainer of the package(s) the changed bugs are assigned to. Additionally the mail to the server and the resulting changes are logged in the bug report and thereby available in the WWW pages.

Please see the introduction to the request server available on the World Wide Web, in the file bug-log-mailserver.txt, or by sending help to either mailserver, for details of the basics of operating the mailservers and the common commands available when mailing either address.

The reference card for the mailservers is available via the WWW, in bug-mailserver-refcard.txt or by email using the refcard command.

Commands available at the control mailserver

General Versioning Duplicates Misc.
reassign bugnumber package [ version ]

Records that bug #bugnumber is a bug in package. This can be used to set the package if the user forgot the pseudo-header, or to change an earlier assignment. No notifications are sent to anyone (other than the usual information in the processing transcript).

If you supply a version, the bug tracking system will note that the bug affects that version of the newly-assigned package.

You can assign a bug to two packages at once by separating the package names with a comma. However, you should only do this if the bug can be fixed by a change to either package. If this is not the case, you should clone the bug and reassign the clone to the other package.

reopen bugnumber [ originator-address | = | ! ]

Reopens #bugnumber if it is closed.

By default, or if you specify =, the original submitter is still as the originator of the report, so that they will get the ack when it is closed again.

If you supply an originator-address the originator will be set to the address you supply. If you wish to become the new originator of the reopened report you can use the ! shorthand or specify your own email address.

It is usually a good idea to tell the person who is about to be recorded as the originator that you're reopening the report, so that they will know to expect the ack which they'll get when it is closed again.

If the bug is not closed then reopen won't do anything, not even change the originator. To change the originator of an open bug report, use the submitter command; note that this will inform the original submitter of the change.

If the bug was recorded as being closed in a particular version of a package but recurred in a later version, it is better to use the found command instead.

found bugnumber [ version ]

Record that #bugnumber has been encountered in the given version of the package to which it is assigned. version may be a fully qualified version, of the form sourcepackagename/version.

The bug tracking system uses this information, in conjunction with fixed versions recorded when closing bugs, to display lists of bugs open in various versions of each package. It considers a bug to be open when it has no fixed version, or when it has been found more recently than it has been fixed.

If no version is given, then the list of fixed versions for the bug is cleared. This is identical to the behaviour of reopen. version may be a fully qualified version, of the form sourcepackagename/version.

This command will only cause a bug to be marked as not done if no version is specified, or if the version being marked found is equal to or greater than the highest version marked fixed. (If you are certain that you want the bug marked as not done, use reopen in conjunction with found.)

This command was introduced in preference to reopen because it was difficult to add a version to that command's syntax without suffering ambiguity.

notfound bugnumber version

Remove the record that #bugnumber was encountered in the given version of the package to which it is assigned. version may be a fully qualified version, of the form sourcepackagename/version.

This differs from closing the bug at that version in that the bug is not listed as fixed in that version either; no information about that version will be known. It is intended for fixing mistakes in the record of when a bug was found.

fixed bugnumber version

Indicate that bug #bugnumber was fixed in the given version of the package to which it is assigned. version may be a fully qualified version, of the form sourcepackagename/version.

This does not cause the bug to be marked as closed, it merely adds another version in which the bug was fixed. Use the bugnumber-done address to close a bug and mark it fixed in a particular version.

notfixed bugnumber version

Remove the record that bug #bugnumber has been fixed in the given version. version may be a fully qualified version, of the form sourcepackagename/version.

This command is equivalent to found followed by notfound (the found removes the fixed at a particular version, and notfound removes the found) with the exception that the bug is not reopened if the found version is greater than any existing fixed version. It is intended for fixing mistakes in the record of when a bug was fixed; in most cases, you actually want found, not notfixed.

submitter bugnumber originator-address | !

Changes the originator of #bugnumber to originator-address.

If you wish to become the new originator of the report you can use the ! shorthand or specify your own email address.

While the reopen command changes the originator of other bugs merged with the one being reopened, submitter does not affect merged bugs.

forwarded bugnumber address

Notes that bugnumber has been forwarded to the upstream maintainer at address. This does not actually forward the report. This can be used to change an existing incorrect forwarded-to address, or to record a new one for a bug that wasn't previously noted as having been forwarded. address should generally be a URI, or possibly an email address. Using a URI where possible allows tools to query a remote bug tracking system (such as bugzilla) for a bug's status.

Example usage: 

      forwarded 12345 http://bugz.illa.foo/cgi/54321
notforwarded bugnumber

Forgets any idea that bugnumber has been forwarded to any upstream maintainer. If the bug was not recorded as having been forwarded then this will do nothing.

retitle bugnumber new-title

Changes the title of a bug report to that specified (the default is the Subject mail header from the original report). Will also change the titles of all bug reports which this bug is merged with.

severity bugnumber severity

Set the severity level for bug report #bugnumber to severity. No notification is sent to the user who reported the bug.

Severities are .

For their meanings please consult the general developers' documentation for the bug system.

affects bugnumber [ + | - | = ] package [ package ... ]

Indicates that a bug affects another package. In the case where bugnumber causes breakage in package even though the bug is actually present in the package to which it is assigned, this causes the bug to be listed by default in the package list of package. This should generally be used where the bug is severe enough to cause multiple reports from users to be assigned to the wrong package. = sets the affects to the list of packages given, and is the default action if no packages are given; - removes the given packages from the affects list; + adds the given packages to the affects list, and is the default if packages are given.

summary bugnumber [message number | summary text]

Selects a message to use as a summary of a bug. The first non-pseudoheader/non-control paragraph of that message is parsed and set as the summary of the bug which is displayed on the top of the bug report page. This is useful in cases where the original report doesn't correctly describe the problem or the bug has many messages which make it difficult to identify the actual problem.

If message number is not given, clears the summary. message number is the message number as listed in the bugreport cgi script output; if a message number of 0 is given, the current message is used (that is, the message which was sent to control@bugs.debian.org which contains the summary control command).

If message number is not numerical and not the empty string, it is assumed to be the text to set the summary to.

outlook bugnumber [message number | outlook text]

Selects a message to use as the outlook for fixing a bug (or the current status of fixing a bug). The first non-pseudoheader/non-control paragraph of that message is parsed and set as the outlook of the bug which is displayed on the top of the bug report page. This is useful to coordinate with others who are working on fixing this bug (for example, in an bug squashing party).

If message number is not given, clears the outlook. message number is the message number as listed in the bugreport cgi script output; if a message number of 0 is given, the current message is used (that is, the message which was sent to control@bugs.debian.org which contains the outlook control command).

If message number is not numerical and not the empty string, it is assumed to be the text to set the outlook to.

clone bugnumber NewID [ new IDs ... ]

The clone control command allows you to duplicate a bug report. It is useful in the case where a single report actually indicates that multiple distinct bugs have occurred. New IDs are negative numbers, separated by spaces, which may be used in subsequent control commands to refer to the newly duplicated bugs. A new report is generated for each new ID.

Example usage: 

          clone 12345 -1 -2
          reassign -1 foo
          retitle -1 foo: foo sucks
          reassign -2 bar
          retitle -2 bar: bar sucks when used with foo
          severity -2 wishlist
          clone 123456 -3
          reassign -3 foo
          retitle -3 foo: foo sucks
          merge -1 -3
merge bugnumber bugnumber ...

Merges two or more bug reports. When reports are merged opening, closing, marking or unmarking as forwarded and reassigning any of the bugs to a new package will have an identical effect on all of the merged reports.

Before bugs can be merged they must be in exactly the same state: either all open or all closed, with the same forwarded-to upstream author address or all not marked as forwarded, all assigned to the same package or package(s) (an exact string comparison is done on the package to which the bug is assigned), and all of the same severity. If they don't start out in the same state you should use reassign, reopen and so forth to make sure that they are before using merge. Titles are not required to match, and will not be affected by the merge. Tags are not required to match, either, they will be joined.

If any of the bugs listed in a merge command is already merged with another bug then all the reports merged with any of the ones listed will all be merged together. Merger is like equality: it is reflexive, transitive and symmetric.

Merging reports causes a note to appear on each report's logs; on the WWW pages this is includes links to the other bugs.

Merged reports are all expired simultaneously, and only when all of the reports each separately meet the criteria for expiry.

forcemerge bugnumber bugnumber ...

Forcibly merges two or more bug reports. The settings of the first bug listed which must be equal in a normal merge are assigned to the bugs listed next. To avoid typos erroneously merging bugs, bugs must be in the same package. See the text above for a description of what merging means.

Note that this makes it possible to close bugs by merging; you are responsible for notifying submitters with an appropriate close message if you do this.

unmerge bugnumber

Disconnects a bug report from any other reports with which it may have been merged. If the report listed is merged with several others then they are all left merged with each other; only their associations with the bug explicitly named are removed.

If many bug reports are merged and you wish to split them into two separate groups of merged reports you must unmerge each report in one of the new groups separately and then merge them into the required new group.

You can only unmerge one report with each unmerge command; if you want to disconnect more than one bug simply include several unmerge commands in your message.

tags bugnumber [ + | - | = ] tag [ tag ... ] [ + | - | = tag ... ] ]

Sets tags for the bug report #bugnumber. No notification is sent to the user who reported the bug. Setting the action to + means to add each tag following, - means to remove each tag following, and = means to set the following tags to the list provided. Intervening +, -, or = change the action for the tags following. The default action is adding.

Example usage: 

          \# same as 'tags 123456 + patch'
          tags 123456 patch

          \# same as 'tags 123456 + help security'
          tags 123456 help security

          \# add 'fixed' and 'pending' tags
          tags 123456 + fixed pending

          \# remove 'unreproducible' tag
          tags 123456 - unreproducible

          \# set tags to exactly 'moreinfo' and 'unreproducible'
          tags 123456 = moreinfo unreproducible
	  
	  \# remove the moreinfo tag and add a patch tag
	  tags 123456 - moreinfo + patch

Available tags currently include .

For their meanings please consult the general developers' documentation for the bug system.

block bugnumber by bug ...
Note that the fix for the first bug is blocked by the other listed bugs.
unblock bugnumber by bug ...
Note that the fix for the first bug is no longer blocked by the other listed bugs.
close bugnumber [ fixed-version ] (deprecated)

Close bug report #bugnumber.

A notification is sent to the user who reported the bug, but (in contrast to mailing bugnumber-done@bugs.debian.org) the text of the mail which caused the bug to be closed is not included in that notification. The maintainer who closes a report needs to ensure, probably by sending a separate message, that the user who reported the bug knows why it is being closed. The use of this command is therefore deprecated. See the developer's information about how to close a bug properly.

If you supply a fixed-version, the bug tracking system will note that the bug was fixed in that version of the package.

package [ packagename ... ]

Limits the following commands so that they will only apply to bugs filed against the listed packages. You can list one or more packages. If you don't list any packages, the following commands will apply to all bugs. You're encouraged to use this as a safety feature in case you accidentally use the wrong bug numbers.

Example usage: 

          package foo
          reassign 123456 bar 1.0-1

          package bar
          retitle 123456 bar: bar sucks
          severity 123456 normal

          package
          severity 234567 wishlist
owner bugnumber address | !

Sets address to be the owner of #bugnumber. The owner of a bug claims responsibility for fixing it. This is useful to share out work in cases where a package has a team of maintainers.

If you wish to become the owner of the bug yourself, you can use the ! shorthand or specify your own email address.

noowner bugnumber
Forgets any idea that the bug has an owner other than the usual maintainer. If the bug had no owner recorded then this will do nothing.
archive bugnumber
Archives a bug that had been archived at some point in the past but is currently not archived if the bug fulfills the requirements for archival, ignoring time.
unarchive bugnumber
Unarchives a bug that was previously archived. Unarchival should generally be coupled with reopen and found/fixed as appropriate. Bugs that have been unarchived can be archived using archive assuming the non-time based archival requirements are met. You should not be using unarchive to make trivial changes to archived bugs, such as changing the submitter; its primary purpose is to allow for the reopening of bugs which have been archived without the intervention of BTS administrators.
#...
One-line comment. The # must be at the start of the line. The text of comments will be included in the acknowledgement sent to the sender and to affected maintainers, so you can use this to document the reasons for your commands.
quit
stop
thank
thanks
thankyou
thank you
--
On a line by itself, in any case, possibly followed by whitespace, tells the control server to stop processing the message; the remainder of the message can include explanations, signatures or anything else, none of it will be detected by the control server.
doc-debian-6.1/doc/constitution.1.2.wml0000664000000000000000000010016212037617006014566 0ustar

Historical version of the Constitution for the Debian Project (v1.2)

Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 ratified on December 2nd, 1998. Superseded by version 1.3, ratified on September 24th, 2006. That was superseded by the current version, 1.4 ratified on October 7th, 2007.

1. Introduction

The Debian Project is an association of individuals who have made common cause to create a free operating system.

This document describes the organisational structure for formal decision-making in the Project. It does not describe the goals of the Project or how it achieves them, or contain any policies except those directly related to the decision-making process.

2. Decision-making bodies and individuals

Each decision in the Project is made by one or more of the following:

  1. The Developers, by way of General Resolution or an election;
  2. The Project Leader;
  3. The Technical Committee and/or its Chairman;
  4. The individual Developer working on a particular task;
  5. Delegates appointed by the Project Leader for specific tasks;
  6. The Project Secretary.

Most of the remainder of this document will outline the powers of these bodies, their composition and appointment, and the procedure for their decision-making. The powers of a person or body may be subject to review and/or limitation by others; in this case the reviewing body or person's entry will state this. In the list above, a person or body is usually listed before any people or bodies whose decisions they can overrule or who they (help) appoint - but not everyone listed earlier can overrule everyone listed later.

2.1. General rules

  1. Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them.

  2. A person may hold several posts, except that the Project Leader, Project Secretary and the Chairman of the Technical Committee must be distinct, and that the Leader cannot appoint themselves as their own Delegate.

  3. A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly.

3. Individual Developers

3.1. Powers

An individual Developer may

  1. make any technical or nontechnical decision with regard to their own work;
  2. propose or sponsor draft General Resolutions;
  3. propose themselves as a Project Leader candidate in elections;
  4. vote on General Resolutions and in Leadership elections.

3.2. Composition and appointment

  1. Developers are volunteers who agree to further the aims of the Project insofar as they participate in it, and who maintain package(s) for the Project or do other work which the Project Leader's Delegate(s) consider worthwhile.

  2. The Project Leader's Delegate(s) may choose not to admit new Developers, or expel existing Developers. If the Developers feel that the Delegates are abusing their authority they can of course override the decision by way of General Resolution - see §4.1(3), §4.2.

3.3. Procedure

Developers may make these decisions as they see fit.

4. The Developers by way of General Resolution or election

4.1. Powers

Together, the Developers may:

  1. Appoint or recall the Project Leader.

  2. Amend this constitution, provided they agree with a 3:1 majority.

  3. Override any decision by the Project Leader or a Delegate.

  4. Override any decision by the Technical Committee, provided they agree with a 2:1 majority.

  5. Issue, supersede and withdraw nontechnical policy documents and statements.

    These include documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software licence terms that Debian software must meet.

    They may also include position statements about issues of the day.

    1. A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes.
    2. The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines.
    3. A Foundation Document requires a 3:1 majority for its supersession. New Foundation Documents are issued and existing ones withdrawn by amending the list of Foundation Documents in this constitution.

  6. Together with the Project Leader and SPI, make decisions about property held in trust for purposes related to Debian. (See §9.1.)

4.2. Procedure

  1. The Developers follow the Standard Resolution Procedure, below. A resolution or amendment is introduced if proposed by any Developer and sponsored by at least K other Developers, or if proposed by the Project Leader or the Technical Committee.

  2. Delaying a decision by the Project Leader or their Delegate:

    1. If the Project Leader or their Delegate, or the Technical Committee, has made a decision, then Developers can override them by passing a resolution to do so; see §4.1(3).
    2. If such a resolution is sponsored by at least 2K Developers, or if it is proposed by the Technical Committee, the resolution puts the decision immediately on hold (provided that resolution itself says so).
    3. If the original decision was to change a discussion period or a voting period, or the resolution is to override the Technical Committee, then only K Developers need to sponsor the resolution to be able to put the decision immediately on hold.
    4. If the decision is put on hold, an immediate vote is held to determine whether the decision will stand until the full vote on the decision is made or whether the implementation of the original decision will be delayed until then. There is no quorum for this immediate procedural vote.
    5. If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted.

  3. Votes are taken by the Project Secretary. Votes, tallies, and results are not revealed during the voting period; after the vote the Project Secretary lists all the votes cast. The voting period is 2 weeks, but may be varied by up to 1 week by the Project Leader.

  4. The minimum discussion period is 2 weeks, but may be varied by up to 1 week by the Project Leader. The Project Leader has a casting vote. There is a quorum of 3Q.

  5. Proposals, sponsors, amendments, calls for votes and other formal actions are made by announcement on a publicly-readable electronic mailing list designated by the Project Leader's Delegate(s); any Developer may post there.

  6. Votes are cast by email in a manner suitable to the Secretary. The Secretary determines for each poll whether voters can change their votes.

  7. Q is half of the square root of the number of current Developers. K is Q or 5, whichever is the smaller. Q and K need not be integers and are not rounded.

5. Project Leader

5.1. Powers

The Project Leader may:

  1. Appoint Delegates or delegate decisions to the Technical Committee.

    The Leader may define an area of ongoing responsibility or a specific decision and hand it over to another Developer or to the Technical Committee.

    Once a particular decision has been delegated and made the Project Leader may not withdraw that delegation; however, they may withdraw an ongoing delegation of particular area of responsibility.

  2. Lend authority to other Developers.

    The Project Leader may make statements of support for points of view or for other members of the project, when asked or otherwise; these statements have force if and only if the Leader would be empowered to make the decision in question.

  3. Make any decision which requires urgent action.

    This does not apply to decisions which have only become gradually urgent through lack of relevant action, unless there is a fixed deadline.

  4. Make any decision for whom noone else has responsibility.

  5. Propose draft General Resolutions and amendments.

  6. Together with the Technical Committee, appoint new members to the Committee. (See §6.2.)

  7. Use a casting vote when Developers vote.

    The Project Leader also has a normal vote in such ballots.

  8. Vary the discussion period for Developers' votes (as above).

  9. Lead discussions amongst Developers.

    The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand. The Project Leader should not use the Leadership position to promote their own personal views.

  10. Together with SPI, make decisions affecting property held in trust for purposes related to Debian. (See §9.1.)

5.2. Appointment

  1. The Project Leader is elected by the Developers.
  2. The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately.
  3. For the following three weeks any Developer may nominate themselves as a candidate Project Leader.
  4. For three weeks after that no more candidates may be nominated; candidates should use this time for campaigning (to make their identities and positions known). If there are no candidates at the end of the nomination period then the nomination period is extended for three further weeks, repeatedly if necessary.
  5. The next three weeks are the polling period during which Developers may cast their votes. Votes in leadership elections are kept secret, even after the election is finished.
  6. The options on the ballot will be those candidates who have nominated themselves and have not yet withdrawn, plus None Of The Above. If None Of The Above wins the election then the election procedure is repeated, many times if necessary.
  7. The decision will be made using the method specified in section §A.6 of the Standard Resolution Procedure. The quorum is the same as for a General Resolution (§4.2) and the default option is None Of The Above.
  8. The Project Leader serves for one year from their election.

5.3. Procedure

The Project Leader should attempt to make decisions which are consistent with the consensus of the opinions of the Developers.

Where practical the Project Leader should informally solicit the views of the Developers.

The Project Leader should avoid overemphasizing their own point of view when making decisions in their capacity as Leader.

6. Technical committee

6.1. Powers

The Technical Committee may:

  1. Decide on any matter of technical policy.

    This includes the contents of the technical policy manuals, developers' reference materials, example packages and the behaviour of non-experimental package building tools. (In each case the usual maintainer of the relevant software or documentation makes decisions initially, however; see 6.3(5).)

  2. Decide any technical matter where Developers' jurisdictions overlap.

    In cases where Developers need to implement compatible technical policies or stances (for example, if they disagree about the priorities of conflicting packages, or about ownership of a command name, or about which package is responsible for a bug that both maintainers agree is a bug, or about who should be the maintainer for a package) the technical committee may decide the matter.

  3. Make a decision when asked to do so.

    Any person or body may delegate a decision of their own to the Technical Committee, or seek advice from it.

  4. Overrule a Developer (requires a 3:1 majority).

    The Technical Committee may ask a Developer to take a particular technical course of action even if the Developer does not wish to; this requires a 3:1 majority. For example, the Committee may determine that a complaint made by the submitter of a bug is justified and that the submitter's proposed solution should be implemented.

  5. Offer advice.

    The Technical Committee may make formal announcements about its views on any matter. Individual members may of course make informal statements about their views and about the likely views of the committee.

  6. Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.)

  7. Appoint the Chairman of the Technical Committee.

    The Chairman is elected by the Committee from its members. All members of the committee are automatically nominated; the committee votes starting one week before the post will become vacant (or immediately, if it is already too late). The members may vote by public acclamation for any fellow committee member, including themselves; there is no default option. The vote finishes when all the members have voted, or when the voting period has ended. The result is determined using the method specified in section A.6 of the Standard Resolution Procedure.

  8. The Chairman can stand in for the Leader, together with the Secretary

    As detailed in §7.1(2), the Chairman of the Technical Committee and the Project Secretary may together stand in for the Leader if there is no Leader.

6.2. Composition

  1. The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members.

  2. When there are fewer than 8 members the Technical Committee may recommend new member(s) to the Project Leader, who may choose (individually) to appoint them or not.

  3. When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6.

  4. When there have been 5 members or fewer for at least one week the Project Leader may appoint new member(s) until the number of members reaches 6, at intervals of at least one week per appointment.

  5. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee.

6.3. Procedure

  1. The Technical Committee uses the Standard Resolution Procedure.

    A draft resolution or amendment may be proposed by any member of the Technical Committee. There is no minimum discussion period; the voting period lasts for up to one week, or until the outcome is no longer in doubt. Members may change their votes. There is a quorum of two.

  2. Details regarding voting

    The Chairman has a casting vote. When the Technical Committee votes whether to override a Developer who also happens to be a member of the Committee, that member may not vote (unless they are the Chairman, in which case they may use only their casting vote).

  3. Public discussion and decision-making.

    Discussion, draft resolutions and amendments, and votes by members of the committee, are made public on the Technical Committee public discussion list. There is no separate secretary for the Committee.

  4. Confidentiality of appointments.

    The Technical Committee may hold confidential discussions via private email or a private mailing list or other means to discuss appointments to the Committee. However, votes on appointments must be public.

  5. No detailed design work.

    The Technical Committee does not engage in design of new proposals and policies. Such design work should be carried out by individuals privately or together and discussed in ordinary technical policy and design forums.

    The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere.

    Individual members of the technical committee may of course participate on their own behalf in any aspect of design and policy work.

  6. Technical Committee makes decisions only as last resort.

    The Technical Committee does not make a technical decision until efforts to resolve it via consensus have been tried and failed, unless it has been asked to make a decision by the person or body who would normally be responsible for it.

7. The Project Secretary

7.1. Powers

The Secretary:

  1. Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution.

  2. Can stand in for the Leader, together with the Chairman of the Technical Committee.

    If there is no Project Leader then the Chairman of the Technical Committee and the Project Secretary may by joint agreement make decisions if they consider it imperative to do so.

  3. Adjudicates any disputes about interpretation of the constitution.

  4. May delegate part or all of their authority to someone else, or withdraw such a delegation at any time.

7.2. Appointment

The Project Secretary is appointed by the Project Leader and the current Project Secretary.

If the Project Leader and the current Project Secretary cannot agree on a new appointment they must ask the board of SPI (see §9.1.) to appoint a Secretary.

If there is no Project Secretary or the current Secretary is unavailable and has not delegated authority for a decision then the decision may be made or delegated by the Chairman of the Technical Committee, as Acting Secretary.

The Project Secretary's term of office is 1 year, at which point they or another Secretary must be (re)appointed.

7.3. Procedure

The Project Secretary should make decisions which are fair and reasonable, and preferably consistent with the consensus of the Developers.

When acting together to stand in for an absent Project Leader the Chairman of the Technical Committee and the Project Secretary should make decisions only when absolutely necessary and only when consistent with the consensus of the Developers.

8. The Project Leader's Delegates

8.1. Powers

The Project Leader's Delegates:

  1. have powers delegated to them by the Project Leader;
  2. may make certain decisions which the Leader may not make directly, including approving or expelling Developers or designating people as Developers who do not maintain packages. This is to avoid concentration of power, particularly over membership as a Developer, in the hands of the Project Leader.

8.2. Appointment

The Delegates are appointed by the Project Leader and may be replaced by the Leader at the Leader's discretion. The Project Leader may not make the position as a Delegate conditional on particular decisions by the Delegate, nor may they override a decision made by a Delegate once made.

8.3. Procedure

Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion.

9. Software in the Public Interest

SPI and Debian are separate organisations who share some goals. Debian is grateful for the legal support framework offered by SPI. Debian's Developers are currently members of SPI by virtue of their status as Developers.

9.1. Authority

  1. SPI has no authority regarding Debian's technical or nontechnical decisions, except that no decision by Debian with respect to any property held by SPI shall require SPI to act outside its legal authority, and that Debian's constitution may occasionally use SPI as a decision body of last resort.
  2. Debian claims no authority over SPI other than that over the use of certain of SPI's property, as described below, though Debian Developers may be granted authority within SPI by SPI's rules.
  3. Debian Developers are not agents or employees of SPI, or of each other or of persons in authority in the Debian Project. A person acting as a Developer does so as an individual, on their own behalf.

9.2. Management of property for purposes related to Debian

Since Debian has no authority to hold money or property, any donations for the Debian Project must be made to SPI, which manages such affairs.

SPI have made the following undertakings:

  1. SPI will hold money, trademarks and other tangible and intangible property and manage other affairs for purposes related to Debian.
  2. Such property will be accounted for separately and held in trust for those purposes, decided on by Debian and SPI according to this section.
  3. SPI will not dispose of or use property held in trust for Debian without approval from Debian, which may be granted by the Project Leader or by General Resolution of the Developers.
  4. SPI will consider using or disposing of property held in trust for Debian when asked to do so by the Project Leader.
  5. SPI will use or dispose of property held in trust for Debian when asked to do so by a General Resolution of the Developers, provided that this is compatible with SPI's legal authority.
  6. SPI will notify the Developers by electronic mail to a Debian Project mailing list when it uses or disposes of property held in trust for Debian.

A. Standard Resolution Procedure

These rules apply to communal decision-making by committees and plebiscites, where stated above.

A.1. Proposal

The formal procedure begins when a draft resolution is proposed and sponsored, as required.

A.1. Discussion and Amendment

  1. Following the proposal, the resolution may be discussed. Amendments may be made formal by being proposed and sponsored according to the requirements for a new resolution, or directly by the proposer of the original resolution.
  2. A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match.
  3. If a formal amendment is not accepted, or one of the sponsors of the resolution does not agree with the acceptance by the proposer of a formal amendment, the amendment remains as an amendment and will be voted on.
  4. If an amendment accepted by the original proposer is not to the liking of others, they may propose another amendment to reverse the earlier change (again, they must meet the requirements for proposer and sponsor(s).)
  5. The proposer of a resolution may suggest changes to the wordings of amendments; these take effect if the proposer of the amendment agrees and none of the sponsors object. In this case the changed amendments will be voted on instead of the originals.
  6. The proposer of a resolution may make changes to correct minor errors (for example, typographical errors or inconsistencies) or changes which do not alter the meaning, providing noone objects within 24 hours. In this case the minimum discussion period is not restarted.

A.2. Calling for a vote

  1. The proposer or a sponsor of a motion or an amendment may call for a vote, providing that the minimum discussion period (if any) has elapsed.
  2. The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments.
  3. The person who calls for a vote states what they believe the wordings of the resolution and any relevant amendments are, and consequently what form the ballot should take. However, the final decision on the form of ballot(s) is the Secretary's - see 7.1(1), 7.1(3) and A.3(4).
  4. The minimum discussion period is counted from the time the last formal amendment was accepted, or since the whole resolution was proposed if no amendments have been proposed and accepted.

A.3. Voting procedure

  1. Each resolution and its related amendments is voted on in a single ballot that includes an option for the original resolution, each amendment, and the default option (where applicable).
  2. The default option must not have any supermajority requirements. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement.
  3. The votes are counted according to the rules in A.6. The default option is Further Discussion, unless specified otherwise.
  4. In cases of doubt the Project Secretary shall decide on matters of procedure.

A.4. Withdrawing resolutions or unaccepted amendments

The proposer of a resolution or unaccepted amendment may withdraw it. In this case new proposers may come forward keep it alive, in which case the first person to do so becomes the new proposer and any others become sponsors if they aren't sponsors already.

A sponsor of a resolution or amendment (unless it has been accepted) may withdraw.

If the withdrawal of the proposer and/or sponsors means that a resolution has no proposer or not enough sponsors it will not be voted on unless this is rectified before the resolution expires.

A.5. Expiry

If a proposed resolution has not been discussed, amended, voted on or otherwise dealt with for 4 weeks the secretary may issue a statement that the issue is being withdrawn. If none of the sponsors of any of the proposals object within a week, the issue is withdrawn.

The secretary may also include suggestions on how to proceed, if appropriate.

A.6. Vote Counting

  1. Each voter's ballot ranks the options being voted on. Not all options need be ranked. Ranked options are considered preferred to all unranked options. Voters may rank options equally. Unranked options are considered to be ranked equally with one another. Details of how ballots may be filled out will be included in the Call For Votes.
  2. If the ballot has a quorum requirement R any options other than the default option which do not receive at least R votes ranking that option above the default option are dropped from consideration.
  3. Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration.
    1. Given two options A and B, V(A,B) is the number of voters who prefer option A over option B.
    2. An option A defeats the default option D by a majority ratio N, if V(A,D) is strictly greater than N * V(D,A).
    3. If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1.
  4. From the list of undropped options, we generate a list of pairwise defeats.
    1. An option A defeats an option B, if V(A,B) is strictly greater than V(B,A).
  5. From the list of [undropped] pairwise defeats, we generate a set of transitive defeats.
    1. An option A transitively defeats an option C if A defeats C or if there is some other option B where A defeats B AND B transitively defeats C.
  6. We construct the Schwartz set from the set of transitive defeats.
    1. An option A is in the Schwartz set if for all options B, either A transitively defeats B, or B does not transitively defeat A.
  7. If there are defeats between options in the Schwartz set, we drop the weakest such defeats from the list of pairwise defeats, and return to step 5.
    1. A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) is less than V(B,Y). Also, (A,X) is weaker than (B,Y) if V(A,X) is equal to V(B,Y) and V(X,A) is greater than V(Y,B).
    2. A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat.
  8. If there are no defeats within the Schwartz set, then the winner is chosen from the options in the Schwartz set. If there is only one such option, it is the winner. If there are multiple options, the elector with the casting vote chooses which of those options wins.

Note: Options which the voters rank above the default option are options they find acceptable. Options ranked below the default options are options they find unacceptable.

When the Standard Resolution Procedure is to be used, the text which refers to it must specify what is sufficient to have a draft resolution proposed and/or sponsored, what the minimum discussion period is, and what the voting period is. It must also specify any supermajority and/or the quorum (and default option) to be used.

B. Use of language and typography

The present indicative (is, for example) means that the statement is a rule in this constitution. May or can indicates that the person or body has discretion. Should means that it would be considered a good thing if the sentence were obeyed, but it is not binding. Text marked as a citation, such as this, is rationale and does not form part of the constitution. It may be used only to aid interpretation in cases of doubt.

doc-debian-6.1/doc/Makefile0000664000000000000000000000612412060350761012445 0ustar # Makefile to build the txt and html files for the # doc-debian package LANGUAGE = english # Adjust this (or create a symlink) to the location of your webml copy (if you have one) # If this directory does not exist the 'update' call will not be able to run, read # the README-build file to know how to set it up WEBWML = ~/debian/www/webwml/$(LANGUAGE) WMLFILES= \ bug-log-access.wml bug-maint-mailcontrol.wml constitution.1.0.wml \ bug-log-mailserver.wml bug-reporting.wml \ bug-mailserver-refcard.wml constitution.wml social-contract.wml \ bug-maint-info.wml constitution.1.1.wml social-contract.1.0.wml \ constitution.1.2.wml social-contract.wml constitution.1.3.wml # These are the automatic files we can generate: TXTFILES = $(subst .wml,.txt,$(WMLFILES)) HTMLFILES = $(subst .wml,.html,$(WMLFILES)) GENERATED_FILES = $(TXTFILES) $(HTMLFILES) # Mailing lists does not have an associated wml file, so we add it separately # to keep GENERATED_FILES to be just those that are built with the Makefile all: $(TXTFILES) wml: $(WMLFILES) update: @$(MAKE) wml clean: -rm -f $(GENERATED_FILES) realclean: clean -rm -f $(WMLFILES) %.html: %.wml wml -q $< >$@ %.txt: %.html lynx -dump -nolist $< >$@ # These rules are conditioned to the existence of $(WEBWML) # so that the package can be built regardless of its existence # Warning: hack webwmlexists := $(shell ls -d $(WEBWML) 2>/dev/null) ifneq "$(webwmlexists)" "" bug-log-access.wml: $(WEBWML)/Bugs/Access.wml cat $< |grep -v ^# >$@ bug-log-mailserver.wml: $(WEBWML)/Bugs/server-request.wml cat $< |grep -v ^# >$@ bug-mailserver-refcard.wml: $(WEBWML)/Bugs/server-refcard.wml cat $< |grep -v ^# >$@ bug-maint-info.wml: $(WEBWML)/Bugs/Developer.wml cat $< |grep -v ^# >$@ bug-maint-mailcontrol.wml: $(WEBWML)/Bugs/server-control.wml cat $< |grep -v ^# >$@ bug-reporting.wml: $(WEBWML)/Bugs/Reporting.wml cat $< |grep -v ^# >$@ constitution.wml: $(WEBWML)/devel/constitution.wml cat $< | perl -pe 's//toc-add-entry><\/h2>/' | grep -v ^# >$@ constitution.1.3.wml: $(WEBWML)/devel/constitution.1.3.wml cat $< |grep -v ^# >$@ constitution.1.2.wml: $(WEBWML)/devel/constitution.1.2.wml cat $< |grep -v ^# >$@ constitution.1.1.wml: $(WEBWML)/devel/constitution.1.1.wml cat $< |grep -v ^# >$@ constitution.1.0.wml: $(WEBWML)/devel/constitution.1.0.wml cat $< |grep -v ^# >$@ mailing-lists.wml: $(WEBWML)/MailingLists/subscribe.wml cat $< |grep -v ^# >$@ social-contract.wml: $(WEBWML)/social_contract.wml cat $< |grep -v ^# >$@ social-contract.1.0.wml: $(WEBWML)/social_contract.1.0.wml cat $< |grep -v ^# >$@ mailing-lists.txt: $(WEBWML)/MailingLists/mailing-lists.txt cp $< $@ ## the Makefile in $(WEBWML)/MailingLists needs internet access! $(WEBWML)/MailingLists/mailing-lists.txt: cd $(WEBWML)/MailingLists && $(MAKE) mailing-lists.txt else %.wml: @echo "ERROR: Cannot find $(WEBWML) to regenerate the sources. Please read the TODO." endif # Not in Debian's website, therefore kept in our own SVN: # source-unpack.txt # debian-manifesto doc-debian-6.1/doc/constitution.1.1.wml0000664000000000000000000007703412037617006014600 0ustar

Historical version of the Constitution for the Debian Project (v1.1)

Version 1.1 ratified on June 21st, 2003. Supersedes Version 1.0 ratified on December 2nd, 1998. Superseded by version 1.2, ratified on October 29th, 2003, which was again superseded by version 1.3 ratified on September 24th, 2006. That was superseded by the current version, 1.4 ratified on October 7th, 2007.

1. Introduction

The Debian Project is an association of individuals who have made common cause to create a free operating system.

This document describes the organisational structure for formal decision-making in the Project. It does not describe the goals of the Project or how it achieves them, or contain any policies except those directly related to the decision-making process.

2. Decision-making bodies and individuals

Each decision in the Project is made by one or more of the following:

  1. The Developers, by way of General Resolution or an election;
  2. The Project Leader;
  3. The Technical Committee and/or its Chairman;
  4. The individual Developer working on a particular task;
  5. Delegates appointed by the Project Leader for specific tasks;
  6. The Project Secretary.

Most of the remainder of this document will outline the powers of these bodies, their composition and appointment, and the procedure for their decision-making. The powers of a person or body may be subject to review and/or limitation by others; in this case the reviewing body or person's entry will state this. In the list above, a person or body is usually listed before any people or bodies whose decisions they can overrule or who they (help) appoint - but not everyone listed earlier can overrule everyone listed later.

2.1. General rules

  1. Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them.

  2. A person may hold several posts, except that the Project Leader, Project Secretary and the Chairman of the Technical Committee must be distinct, and that the Leader cannot appoint themselves as their own Delegate.

  3. A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly.

3. Individual Developers

3.1. Powers

An individual Developer may

  1. make any technical or nontechnical decision with regard to their own work;
  2. propose or sponsor draft General Resolutions;
  3. propose themselves as a Project Leader candidate in elections;
  4. vote on General Resolutions and in Leadership elections.

3.2. Composition and appointment

  1. Developers are volunteers who agree to further the aims of the Project insofar as they participate in it, and who maintain package(s) for the Project or do other work which the Project Leader's Delegate(s) consider worthwhile.

  2. The Project Leader's Delegate(s) may choose not to admit new Developers, or expel existing Developers. If the Developers feel that the Delegates are abusing their authority they can of course override the decision by way of General Resolution - see §4.1(3), §4.2.

3.3. Procedure

Developers may make these decisions as they see fit.

4. The Developers by way of General Resolution or election

4.1. Powers

Together, the Developers may:

  1. Appoint or recall the Project Leader.

  2. Amend this constitution, provided they agree with a 3:1 majority.

  3. Override any decision by the Project Leader or a Delegate.

  4. Override any decision by the Technical Committee, provided they agree with a 2:1 majority.

  5. Issue nontechnical policy documents and statements.

    These include documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software licence terms that Debian software must meet.

    They may also include position statements about issues of the day.

  6. Together with the Project Leader and SPI, make decisions about property held in trust for purposes related to Debian. (See §9.1.)

4.2. Procedure

  1. The Developers follow the Standard Resolution Procedure, below. A resolution or amendment is introduced if proposed by any Developer and sponsored by at least K other Developers, or if proposed by the Project Leader or the Technical Committee.

  2. Delaying a decision by the Project Leader or their Delegate:

    1. If the Project Leader or their Delegate, or the Technical Committee, has made a decision, then Developers can override them by passing a resolution to do so; see §4.1(3).
    2. If such a resolution is sponsored by at least 2K Developers, or if it is proposed by the Technical Committee, the resolution puts the decision immediately on hold (provided that resolution itself says so).
    3. If the original decision was to change a discussion period or a voting period, or the resolution is to override the Technical Committee, then only K Developers need to sponsor the resolution to be able to put the decision immediately on hold.
    4. If the decision is put on hold, an immediate vote is held to determine whether the decision will stand until the full vote on the decision is made or whether the implementation of the original decision will be delayed until then. There is no quorum for this immediate procedural vote.
    5. If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted.

  3. Votes are taken by the Project Secretary. Votes, tallies, and results are not revealed during the voting period; after the vote the Project Secretary lists all the votes cast. The voting period is 2 weeks, but may be varied by up to 1 week by the Project Leader.

  4. The minimum discussion period is 2 weeks, but may be varied by up to 1 week by the Project Leader. The Project Leader has a casting vote. There is a quorum of 3Q.

  5. Proposals, sponsors, amendments, calls for votes and other formal actions are made by announcement on a publicly-readable electronic mailing list designated by the Project Leader's Delegate(s); any Developer may post there.

  6. Votes are cast by email in a manner suitable to the Secretary. The Secretary determines for each poll whether voters can change their votes.

  7. Q is half of the square root of the number of current Developers. K is Q or 5, whichever is the smaller. Q and K need not be integers and are not rounded.

5. Project Leader

5.1. Powers

The Project Leader may:

  1. Appoint Delegates or delegate decisions to the Technical Committee.

    The Leader may define an area of ongoing responsibility or a specific decision and hand it over to another Developer or to the Technical Committee.

    Once a particular decision has been delegated and made the Project Leader may not withdraw that delegation; however, they may withdraw an ongoing delegation of particular area of responsibility.

  2. Lend authority to other Developers.

    The Project Leader may make statements of support for points of view or for other members of the project, when asked or otherwise; these statements have force if and only if the Leader would be empowered to make the decision in question.

  3. Make any decision which requires urgent action.

    This does not apply to decisions which have only become gradually urgent through lack of relevant action, unless there is a fixed deadline.

  4. Make any decision for whom noone else has responsibility.

  5. Propose draft General Resolutions and amendments.

  6. Together with the Technical Committee, appoint new members to the Committee. (See §6.2.)

  7. Use a casting vote when Developers vote.

    The Project Leader also has a normal vote in such ballots.

  8. Vary the discussion period for Developers' votes (as above).

  9. Lead discussions amongst Developers.

    The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand. The Project Leader should not use the Leadership position to promote their own personal views.

  10. Together with SPI, make decisions affecting property held in trust for purposes related to Debian. (See §9.1.)

5.2. Appointment

  1. The Project Leader is elected by the Developers.
  2. The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately.
  3. For the following three weeks any Developer may nominate themselves as a candidate Project Leader.
  4. For three weeks after that no more candidates may be nominated; candidates should use this time for campaigning (to make their identities and positions known). If there are no candidates at the end of the nomination period then the nomination period is extended for three further weeks, repeatedly if necessary.
  5. The next three weeks are the polling period during which Developers may cast their votes. Votes in leadership elections are kept secret, even after the election is finished.
  6. The options on the ballot will be those candidates who have nominated themselves and have not yet withdrawn, plus None Of The Above. If None Of The Above wins the election then the election procedure is repeated, many times if necessary.
  7. The decision will be made using the method specified in section §A.6 of the Standard Resolution Procedure. The quorum is the same as for a General Resolution (§4.2) and the default option is None Of The Above.
  8. The Project Leader serves for one year from their election.

5.3. Procedure

The Project Leader should attempt to make decisions which are consistent with the consensus of the opinions of the Developers.

Where practical the Project Leader should informally solicit the views of the Developers.

The Project Leader should avoid overemphasizing their own point of view when making decisions in their capacity as Leader.

6. Technical committee

6.1. Powers

The Technical Committee may:

  1. Decide on any matter of technical policy.

    This includes the contents of the technical policy manuals, developers' reference materials, example packages and the behaviour of non-experimental package building tools. (In each case the usual maintainer of the relevant software or documentation makes decisions initially, however; see 6.3(5).)

  2. Decide any technical matter where Developers' jurisdictions overlap.

    In cases where Developers need to implement compatible technical policies or stances (for example, if they disagree about the priorities of conflicting packages, or about ownership of a command name, or about which package is responsible for a bug that both maintainers agree is a bug, or about who should be the maintainer for a package) the technical committee may decide the matter.

  3. Make a decision when asked to do so.

    Any person or body may delegate a decision of their own to the Technical Committee, or seek advice from it.

  4. Overrule a Developer (requires a 3:1 majority).

    The Technical Committee may ask a Developer to take a particular technical course of action even if the Developer does not wish to; this requires a 3:1 majority. For example, the Committee may determine that a complaint made by the submitter of a bug is justified and that the submitter's proposed solution should be implemented.

  5. Offer advice.

    The Technical Committee may make formal announcements about its views on any matter. Individual members may of course make informal statements about their views and about the likely views of the committee.

  6. Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.)

  7. Appoint the Chairman of the Technical Committee.

    The Chairman is elected by the Committee from its members. All members of the committee are automatically nominated; the committee votes starting one week before the post will become vacant (or immediately, if it is already too late). The members may vote by public acclamation for any fellow committee member, including themselves; there is no default option. The vote finishes when all the members have voted, or when the voting period has ended. The result is determined using the method specified in section A.6 of the Standard Resolution Procedure.

  8. The Chairman can stand in for the Leader, together with the Secretary

    As detailed in §7.1(2), the Chairman of the Technical Committee and the Project Secretary may together stand in for the Leader if there is no Leader.

6.2. Composition

  1. The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members.

  2. When there are fewer than 8 members the Technical Committee may recommend new member(s) to the Project Leader, who may choose (individually) to appoint them or not.

  3. When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6.

  4. When there have been 5 members or fewer for at least one week the Project Leader may appoint new member(s) until the number of members reaches 6, at intervals of at least one week per appointment.

  5. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee.

6.3. Procedure

  1. The Technical Committee uses the Standard Resolution Procedure.

    A draft resolution or amendment may be proposed by any member of the Technical Committee. There is no minimum discussion period; the voting period lasts for up to one week, or until the outcome is no longer in doubt. Members may change their votes. There is a quorum of two.

  2. Details regarding voting

    The Chairman has a casting vote. When the Technical Committee votes whether to override a Developer who also happens to be a member of the Committee, that member may not vote (unless they are the Chairman, in which case they may use only their casting vote).

  3. Public discussion and decision-making.

    Discussion, draft resolutions and amendments, and votes by members of the committee, are made public on the Technical Committee public discussion list. There is no separate secretary for the Committee.

  4. Confidentiality of appointments.

    The Technical Committee may hold confidential discussions via private email or a private mailing list or other means to discuss appointments to the Committee. However, votes on appointments must be public.

  5. No detailed design work.

    The Technical Committee does not engage in design of new proposals and policies. Such design work should be carried out by individuals privately or together and discussed in ordinary technical policy and design forums.

    The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere.

    Individual members of the technical committee may of course participate on their own behalf in any aspect of design and policy work.

  6. Technical Committee makes decisions only as last resort.

    The Technical Committee does not make a technical decision until efforts to resolve it via consensus have been tried and failed, unless it has been asked to make a decision by the person or body who would normally be responsible for it.

7. The Project Secretary

7.1. Powers

The Secretary:

  1. Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution.

  2. Can stand in for the Leader, together with the Chairman of the Technical Committee.

    If there is no Project Leader then the Chairman of the Technical Committee and the Project Secretary may by joint agreement make decisions if they consider it imperative to do so.

  3. Adjudicates any disputes about interpretation of the constitution.

  4. May delegate part or all of their authority to someone else, or withdraw such a delegation at any time.

7.2. Appointment

The Project Secretary is appointed by the Project Leader and the current Project Secretary.

If the Project Leader and the current Project Secretary cannot agree on a new appointment they must ask the board of SPI (see §9.1.) to appoint a Secretary.

If there is no Project Secretary or the current Secretary is unavailable and has not delegated authority for a decision then the decision may be made or delegated by the Chairman of the Technical Committee, as Acting Secretary.

The Project Secretary's term of office is 1 year, at which point they or another Secretary must be (re)appointed.

7.3. Procedure

The Project Secretary should make decisions which are fair and reasonable, and preferably consistent with the consensus of the Developers.

When acting together to stand in for an absent Project Leader the Chairman of the Technical Committee and the Project Secretary should make decisions only when absolutely necessary and only when consistent with the consensus of the Developers.

8. The Project Leader's Delegates

8.1. Powers

The Project Leader's Delegates:

  1. have powers delegated to them by the Project Leader;
  2. may make certain decisions which the Leader may not make directly, including approving or expelling Developers or designating people as Developers who do not maintain packages. This is to avoid concentration of power, particularly over membership as a Developer, in the hands of the Project Leader.

8.2. Appointment

The Delegates are appointed by the Project Leader and may be replaced by the Leader at the Leader's discretion. The Project Leader may not make the position as a Delegate conditional on particular decisions by the Delegate, nor may they override a decision made by a Delegate once made.

8.3. Procedure

Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion.

9. Software in the Public Interest

SPI and Debian are separate organisations who share some goals. Debian is grateful for the legal support framework offered by SPI. Debian's Developers are currently members of SPI by virtue of their status as Developers.

9.1. Authority

  1. SPI has no authority regarding Debian's technical or nontechnical decisions, except that no decision by Debian with respect to any property held by SPI shall require SPI to act outside its legal authority, and that Debian's constitution may occasionally use SPI as a decision body of last resort.
  2. Debian claims no authority over SPI other than that over the use of certain of SPI's property, as described below, though Debian Developers may be granted authority within SPI by SPI's rules.
  3. Debian Developers are not agents or employees of SPI, or of each other or of persons in authority in the Debian Project. A person acting as a Developer does so as an individual, on their own behalf.

9.2. Management of property for purposes related to Debian

Since Debian has no authority to hold money or property, any donations for the Debian Project must be made to SPI, which manages such affairs.

SPI have made the following undertakings:

  1. SPI will hold money, trademarks and other tangible and intangible property and manage other affairs for purposes related to Debian.
  2. Such property will be accounted for separately and held in trust for those purposes, decided on by Debian and SPI according to this section.
  3. SPI will not dispose of or use property held in trust for Debian without approval from Debian, which may be granted by the Project Leader or by General Resolution of the Developers.
  4. SPI will consider using or disposing of property held in trust for Debian when asked to do so by the Project Leader.
  5. SPI will use or dispose of property held in trust for Debian when asked to do so by a General Resolution of the Developers, provided that this is compatible with SPI's legal authority.
  6. SPI will notify the Developers by electronic mail to a Debian Project mailing list when it uses or disposes of property held in trust for Debian.

A. Standard Resolution Procedure

These rules apply to communal decision-making by committees and plebiscites, where stated above.

A.1. Proposal

The formal procedure begins when a draft resolution is proposed and sponsored, as required.

A.1. Discussion and Amendment

  1. Following the proposal, the resolution may be discussed. Amendments may be made formal by being proposed and sponsored according to the requirements for a new resolution, or directly by the proposer of the original resolution.
  2. A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match.
  3. If a formal amendment is not accepted, or one of the sponsors of the resolution does not agree with the acceptance by the proposer of a formal amendment, the amendment remains as an amendment and will be voted on.
  4. If an amendment accepted by the original proposer is not to the liking of others, they may propose another amendment to reverse the earlier change (again, they must meet the requirements for proposer and sponsor(s).)
  5. The proposer of a resolution may suggest changes to the wordings of amendments; these take effect if the proposer of the amendment agrees and none of the sponsors object. In this case the changed amendments will be voted on instead of the originals.
  6. The proposer of a resolution may make changes to correct minor errors (for example, typographical errors or inconsistencies) or changes which do not alter the meaning, providing noone objects within 24 hours. In this case the minimum discussion period is not restarted.

A.2. Calling for a vote

  1. The proposer or a sponsor of a motion or an amendment may call for a vote, providing that the minimum discussion period (if any) has elapsed.
  2. The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments.
  3. The person who calls for a vote states what they believe the wordings of the resolution and any relevant amendments are, and consequently what form the ballot should take. However, the final decision on the form of ballot(s) is the Secretary's - see 7.1(1), 7.1(3) and A.3(4).
  4. The minimum discussion period is counted from the time the last formal amendment was accepted, or since the whole resolution was proposed if no amendments have been proposed and accepted.

A.3. Voting procedure

  1. Each resolution and its related amendments is voted on in a single ballot that includes an option for the original resolution, each amendment, and the default option (where applicable).
  2. The default option must not have any supermajority requirements. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement.
  3. The votes are counted according to the rules in A.6. The default option is Further Discussion, unless specified otherwise.
  4. In cases of doubt the Project Secretary shall decide on matters of procedure.

A.4. Withdrawing resolutions or unaccepted amendments

The proposer of a resolution or unaccepted amendment may withdraw it. In this case new proposers may come forward keep it alive, in which case the first person to do so becomes the new proposer and any others become sponsors if they aren't sponsors already.

A sponsor of a resolution or amendment (unless it has been accepted) may withdraw.

If the withdrawal of the proposer and/or sponsors means that a resolution has no proposer or not enough sponsors it will not be voted on unless this is rectified before the resolution expires.

A.5. Expiry

If a proposed resolution has not been discussed, amended, voted on or otherwise dealt with for 4 weeks the secretary may issue a statement that the issue is being withdrawn. If none of the sponsors of any of the proposals object within a week, the issue is withdrawn.

The secretary may also include suggestions on how to proceed, if appropriate.

A.6. Vote Counting

  1. Each voter's ballot ranks the options being voted on. Not all options need be ranked. Ranked options are considered preferred to all unranked options. Voters may rank options equally. Unranked options are considered to be ranked equally with one another. Details of how ballots may be filled out will be included in the Call For Votes.
  2. If the ballot has a quorum requirement R any options other than the default option which do not receive at least R votes ranking that option above the default option are dropped from consideration.
  3. Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration.
    1. Given two options A and B, V(A,B) is the number of voters who prefer option A over option B.
    2. An option A defeats the default option D by a majority ratio N, if V(A,D) is strictly greater than N * V(D,A).
    3. If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1.
  4. From the list of undropped options, we generate a list of pairwise defeats.
    1. An option A defeats an option B, if V(A,B) is strictly greater than V(B,A).
  5. From the list of [undropped] pairwise defeats, we generate a set of transitive defeats.
    1. An option A transitively defeats an option C if A defeats C or if there is some other option B where A defeats B AND B transitively defeats C.
  6. We construct the Schwartz set from the set of transitive defeats.
    1. An option A is in the Schwartz set if for all options B, either A transitively defeats B, or B does not transitively defeat A.
  7. If there are defeats between options in the Schwartz set, we drop the weakest such defeats from the list of pairwise defeats, and return to step 5.
    1. A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) is less than V(B,Y). Also, (A,X) is weaker than (B,Y) if V(A,X) is equal to V(B,Y) and V(X,A) is greater than V(Y,B).
    2. A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat.
  8. If there are no defeats within the Schwartz set, then the winner is chosen from the options in the Schwartz set. If there is only one such option, it is the winner. If there are multiple options, the elector with the casting vote chooses which of those options wins.

Note: Options which the voters rank above the default option are options they find acceptable. Options ranked below the default options are options they find unacceptable.

When the Standard Resolution Procedure is to be used, the text which refers to it must specify what is sufficient to have a draft resolution proposed and/or sponsored, what the minimum discussion period is, and what the voting period is. It must also specify any supermajority and/or the quorum (and default option) to be used.

B. Use of language and typography

The present indicative (is, for example) means that the statement is a rule in this constitution. May or can indicates that the person or body has discretion. Should means that it would be considered a good thing if the sentence were obeyed, but it is not binding. Text marked as a citation, such as this, is rationale and does not form part of the constitution. It may be used only to aid interpretation in cases of doubt.

doc-debian-6.1/doc/bug-mailserver-refcard.wml0000664000000000000000000000762612037617006016070 0ustar

Mail servers' reference card

Full documentation of the mail servers is available on the WWW, in the files bug-log-mailserver.txt and bug-maint-mailcontrol.txt or by sending the word help to each mailserver.

Synopsis of commands available at request@bugs.debian.org

  • send bugnumber
  • send-detail bugnumber
  • index [full]
  • index-summary by-package
  • index-summary by-number
  • index-maint
  • index maint maintainer
  • index-packages
  • index packages package
  • send-unmatched [this|0]
  • send-unmatched last|-1
  • send-unmatched old|-2
  • getinfo filename (ftp.debian.org/debian/doc/*)
  • help
  • refcard
  • thanks
  • #... (comment)
  • debug level

Synopsis of extra commands available at control@bugs.debian.org

  • reassign bugnumber package [ version ]
  • severity bugnumber severity
  • reopen bugnumber [ originator-address | = | ! ]
  • found bugnumber [ version ]
  • notfound bugnumber version
  • submitter bugnumber originator-address | !
  • forwarded bugnumber address
  • notforwarded bugnumber
  • owner bugnumber address | !
  • noowner bugnumber
  • retitle bugnumber new-title
  • clone bugnumber NewID [ new IDs ... ]
  • merge bugnumber bugnumber ...
  • unmerge bugnumber
  • forcemerge bugnumber bugnumber ...
  • tag bugnumber [ + | - | = ] tag [ tag ... ]
  • block bugnumber by bug ...
  • unblock bugnumber by bug ...
  • close bugnumber [ fixed-version ] (deprecated — you must separately tell originator why, see Closing bug reports instead)

reopen with = or no originator address leaves the originator as the original submitter; ! sets it to you, the person doing the reopen.

Severities are .

Tags currently include .

Synopsis of bug submission and followup addresses

  • nnn[ -submit | ]
  • nnn-maintonly
  • nnn-quiet
  • nnn-forwarded
  • nnn-request
  • nnn-submitter
  • nnn-done
  • nnn-close
  • nnn-subscribe
doc-debian-6.1/doc/bug-maint-info.wml0000664000000000000000000005530212037617006014346 0ustar

Information regarding the bug processing system for package maintainers and bug triagers

Initially, a bug report is submitted by a user as an ordinary mail message to submit@bugs.debian.org. This will then be given a number, acknowledged to the user, and forwarded to debian-bugs-dist. If the submitter included a Package line listing a package with a known maintainer the maintainer will get a copy too.

The Subject line will have Bug#nnn: added, and the Reply-To will be set to include both the submitter of the report and nnn@bugs.debian.org.

Closing bug reports

Debian bug reports should be closed when the problem is fixed. Problems in packages can only be considered fixed once a package that includes the bug fix enters the Debian archive.

Normally, the only people that should close a bug report are the submitter of the bug and the maintainer(s) of the package against which the bug is filed. There are exceptions to this rule, for example, the bugs filed against unknown packages or certain generic pseudo-packages. When in doubt, don't close bugs, first ask for advice on the debian-devel mailing list.

Bug reports should be closed by sending email to nnn-done@bugs.debian.org. The message body needs to contain an explanation of how the bug was fixed.

With the emails received from the bug tracking system, all you need to do to close the bug is to make a Reply in your mail reader program and edit the To field to say nnn-done@bugs.debian.org instead of nnn@bugs.debian.org (nnn-close is provided as an alias for nnn-done).

Where applicable, please supply a Version line in the pseudo-header of your message when closing a bug, so that the bug tracking system knows which releases of the package contain the fix.

The person closing the bug, the person who submitted it and the debian-bugs-closed mailing list will each get a notification about the change in status of the report. The submitter and the mailing list will also receive the contents of the message sent to nnn-done.

Followup messages

The bug tracking system will include the submitter's address and the bug address (nnn@bugs.debian.org) in the Reply-To header after forwarding the bug report. Please note that these are two distinct addresses.

Any developer wishing to reply to a bug report should simply reply to the message, respecting the Reply-To header. This will not close the bug.

Do not use the reply to all recipients or followup feature of your mailer unless you intend to edit down the recipients substantially. In particular, see that you don't send followup messages to submit@bugs.debian.org.

Messages can be sent to the following addresses in order to be filed in the bug tracking system:

  • nnn@bugs.debian.org — such messages are also sent to the package maintainer and forwarded to debian-bugs-dist, but not to the submitter;
  • nnn-submitter@bugs.debian.org — these are also sent to the submitter and forwarded to debian-bugs-dist, but not to the package maintainer;
  • nnn-maintonly@bugs.debian.org — these are only sent to the package maintainer, not to the submitter or debian-bugs-dist;
  • nnn-quiet@bugs.debian.org — these are only filed in the bug tracking system (as are all the above), not sent to anyone else.

For more information about headers to suppress ACK messages and how to send carbon copies using the Bug Tracking System, see the instructions for reporting bugs.

Severity levels

The bug system records a severity level with each bug report. This is set to normal by default, but can be overridden either by supplying a Severity line in the pseudo-header when the bug is submitted (see the instructions for reporting bugs), or by using the severity command with the control request server.

The severity levels are:

critical
makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package.
grave
makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package.
serious
is a severe violation of Debian policy (roughly, it violates a must or required directive), or, in the package maintainer's or release manager's opinion, makes the package unsuitable for release.
important
a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone.
normal
the default value, applicable to most bugs.
minor
a problem which doesn't affect the package's usefulness, and is presumably trivial to fix.
wishlist
for any feature request, and also for any bugs that are very difficult to fix due to major design considerations.

Certain severities are considered release-critical, meaning the bug will have an impact on releasing the package with the stable release of Debian. Currently, these are critical, grave and serious. For complete and canonical rules on what issues merit these severities, see the list of release-critical issues for the next release.

Tags for bug reports

Each bug can have zero or more of a set of given tags. These tags are displayed in the list of bugs when you look at a package's page, and when you look at the full bug log.

Tags can be set by supplying a Tags line in the pseudo-header when the bug is submitted (see the instructions for reporting bugs), or by using the tags command with the control request server. Separate multiple tags with commas, spaces, or both.

The current bug tags are: . Here is some detailed info about the tags:

patch
A patch or some other easy procedure for fixing the bug is included in the bug logs. If there's a patch, but it doesn't resolve the bug adequately or causes some other problems, this tag should not be used.
wontfix
This bug won't be fixed. Possibly because this is a choice between two arbitrary ways of doing things and the maintainer and submitter prefer different ways of doing things, possibly because changing the behaviour will cause other, worse, problems for others, or possibly for other reasons.
moreinfo
This bug can't be addressed until more information is provided by the submitter. The bug will be closed if the submitter doesn't provide more information in a reasonable (few months) timeframe. This is for bugs like It doesn't work. What doesn't work?
unreproducible
This bug can't be reproduced on the maintainer's system. Assistance from third parties is needed in diagnosing the cause of the problem.
help
The maintainer is requesting help with dealing with this bug.
pending
A solution to this bug has been found and an upload will be made soon.
fixed
This bug is fixed or worked around (by a non-maintainer upload, for example), but there's still an issue that needs to be resolved. This tag replaces the old fixed severity.
security
This bug describes a security problem in a package (e.g., bad permissions allowing access to data that shouldn't be accessible; buffer overruns allowing people to control a system in ways they shouldn't be able to; denial of service attacks that should be fixed, etc). Most security bugs should also be set at critical or grave severity.
upstream
This bug applies to the upstream part of the package.
confirmed
The maintainer has looked at, understands, and basically agrees with the bug, but has yet to fix it. (Use of this tag is optional; it is intended mostly for maintainers who need to manage large numbers of open bugs.)
fixed-upstream
The bug has been fixed by the upstream maintainer, but not yet in the package (for whatever reason: perhaps it is too complicated to backport the change or too minor to be worth bothering).
fixed-in-experimental
The bug has been fixed in the package of the experimental distribution, but not yet in the unstable distribution.
d-i
This bug is relevant to the development of debian-installer. It is expected that this will be used when the bug affects installer development but is not filed against a package that forms a direct part of the installer itself.
ipv6
This bug affects support for Internet Protocol version 6.
lfs
This bug affects support for large files (over 2 gigabytes).
l10n
This bug is relevant to the localisation of the package.
potato
This bug particularly applies to the potato release of Debian.
woody
This bug particularly applies to the woody distribution.
sarge
This is a distribution tag, which has two effects. When set on a bug, the bug can only affect sarge (though it may also affect other distributions if other distribution tags are set) but otherwise normal buggy/fixed/absent rules apply. The bug also should not be archived until it is fixed in sarge.
sarge-ignore
This release-critical bug is to be ignored for the purposes of releasing sarge. This tag should only be used by the release manager; do not set it yourself without explicit authorization from them.
etch
This is a distribution tag, which has two effects. When set on a bug, the bug can only affect etch (though it may also affect other distributions if other distribution tags are set) but otherwise normal buggy/fixed/absent rules apply. The bug also should not be archived until it is fixed in etch.
etch-ignore
This release-critical bug is to be ignored for the purposes of releasing etch. This tag should only be used by the release manager; do not set it yourself without explicit authorization from them.
lenny
This is a release tag, which has two effects. When set on a bug, the bug can only affect lenny (though it may also affect other releases if other release tags are set) but otherwise normal buggy/fixed/absent rules apply. The bug also should not be archived until it is fixed in lenny.
lenny-ignore
This release-critical bug is to be ignored for the purposes of releasing lenny. This tag should only be used by the release manager(s); do not set it yourself without explicit authorization from them.
squeeze
This is a release tag, which has two effects. When set on a bug, the bug can only affect squeeze (though it may also affect other releases if other release tags are set) but otherwise normal buggy/fixed/absent rules apply. The bug also should not be archived until it is fixed in squeeze.
squeeze-ignore
This release-critical bug is to be ignored for the purposes of releasing squeeze. This tag should only be used by the release manager(s); do not set it yourself without explicit authorization from them.
wheezy
This is a release tag, which has two effects. When set on a bug, the bug can only affect wheezy (though it may also affect other releases if other release tags are set) but otherwise normal buggy/fixed/absent rules apply. The bug also should not be archived until it is fixed in wheezy.
wheezy-ignore
This release-critical bug is to be ignored for the purposes of releasing wheezy. This tag should only be used by the release manager(s); do not set it yourself without explicit authorization from them.
sid
This is a release tag, which has two effects. When set on a bug, the bug can only affect sid (though it may also affect other releases if other release tags are set) but otherwise normal buggy/fixed/absent rules apply. The bug also should not be archived until it is fixed in sid.
experimental
This is a release tag, which has two effects. When set on a bug, the bug can only affect experimental (though it may also affect other releases if other release tags are set) but otherwise normal buggy/fixed/absent rules apply. The bug also should not be archived until it is fixed in experimental.

Some info on distribution-specific tags: the -ignore tags ignore the bug for the purposes of testing propagation. The release tags indicate that the bug in question should not be archived until it is fixed in the set of releases specified. The release tags also indicate that a bug should only be considered buggy in the set of releases specified. [In other words, the bug is absent in any release whose corresponding release tag is not set if any release tags are set; otherwise the normal found/fixed rules apply.]

Release tags should not be used if proper versioning of the bug would achieve the desired effect, as they require manual addition and removal. If you are unsure if a release tag is required, contact the Debian BTS Administrators () or the release team for advice.

Recording that you have passed on a bug report

When a developer forwards a bug report to the developer of the upstream source package from which the Debian package is derived, they should note this in the bug tracking system as follows:

Make sure that the To field of your message to the author has only the author(s) address(es) in it; put the person who reported the bug, nnn-forwarded@bugs.debian.org and nnn@bugs.debian.org in the CC field.

Ask the author to preserve the CC to nnn-forwarded@bugs.debian.org when they reply, so that the bug tracking system will file their reply with the original report. These messages are only filed and are not sent on; to send a message as normal, send them to nnn@bugs.debian.org as well.

When the bug tracking system gets a message at nnn-forwarded it will mark the relevant bug as having been forwarded to the address(es) in the To field of the message it gets, if the bug is not already marked as forwarded.

You can also manipulate the forwarded to information by sending messages to control@bugs.debian.org.

Changing bug ownership

In cases where the person responsible for fixing a bug is not the assigned maintainer for the associated package (for example, when the package is maintained by a team), it may be useful to record this fact in the bug tracking system. To help with this, each bug may optionally have an owner.

The owner can be set by supplying an Owner line in the pseudo-header when the bug is submitted (see the instructions for reporting bugs), or by using the owner and noowner commands with the control request server.

Incorrectly listed package maintainers

If the maintainer of a package is listed incorrectly, this is usually because the maintainer has changed recently, and the new maintainer hasn't yet uploaded a new version of the package with a changed Maintainer control file field. This will be fixed when the package is uploaded; alternatively, the archive maintainers can override the maintainer record of a package manually, for example if a rebuild and reupload of the package is not expected to be needed soon. Contact override-change@debian.org for changes to the override file.

Reopening, reassigning and manipulating bugs

It is possible to reassign bug reports to other packages, to reopen erroneously-closed ones, to modify the information saying to where, if anywhere, a bug report has been forwarded, to change the severities and titles of reports, to set the ownership of bugs, to merge and unmerge bug reports, and to record the versions of packages in which bugs were found and in which they were fixed. This is done by sending mail to control@bugs.debian.org.

The format of these messages is described in another document available on the World Wide Web or in the file bug-maint-mailcontrol.txt. A plain text version can also be obtained by mailing the word help to the server at the address above.

Subscribing to bugs

The bug tracking system also allows bug submitters, developers and other interested third parties to subscribe to individual bugs. This feature can be used by those wishing to keep an eye on a bug, without having to subscribe to a package through the PTS. All messages that are received at nnn@bugs.debian.org, are sent to subscribers.

Subscribing to a bug can be done by sending an email to nnn-subscribe@bugs.debian.org. The subject and body of the email are ignored by the BTS. Once this message is processed, users are sent a confirmation message that they will need to reply to before they are sent the messages relating to that bug.

It is also possible to unsubscribe from a bug. Unsubscribing can be done by sending an email to nnn-unsubscribe@bugs.debian.org. The subject and body of the email are again ignored by the BTS. Users will be sent a confirmation message which they must reply to if they wish to be unsubscribed from the bug.

By default, the address subscribed is the one found in the From header. If you wish to subscribe another address to a bug, you will need to encode the address to be subscribed into the subscription message. This takes the form of: nnn-subscribe-\ localpart=\ example.com@bugs.debian.org. That example would send localpart@example.com a subscription message for bug nnn. The @ sign must be encoded by changing it to an = sign. Similarly, an unsubscription takes the form nnn-unsubscribe-localpart\ =example.com@bugs.debian.org. In both cases, the subject and body of the email will be forwarded to the email address within the request for confirmation.

More-or-less obsolete subject-scanning feature

Messages that arrive at submit or bugs whose Subject starts Bug#nnn will be treated as having been sent to nnn@bugs.debian.org. This is both for backwards compatibility with mail forwarded from the old addresses, and to catch followup mail sent to submit by mistake (for example, by using reply to all recipients).

A similar scheme operates for maintonly, done, quiet and forwarded, which treat mail arriving with a Subject tag as having been sent to the corresponding nnn-whatever@bugs.debian.org address.

Messages arriving at plain forwarded and done — ie, with no bug report number in the address — and without a bug number in the Subject will be filed under junk and kept for a few weeks, but otherwise ignored.

Obsolete X-Debian-PR: quiet feature

It used to be possible to prevent the bug tracking system from forwarding anywhere messages it received at debian-bugs, by putting an X-Debian-PR: quiet line in the actual mail header.

This header line is now ignored. Instead, send your message to quiet or nnn-quiet (or maintonly or nnn-maintonly).

doc-debian-6.1/doc/social-contract.wml0000664000000000000000000001747312037617006014626 0ustar {#meta#: :#meta#}

Version 1.1 ratified on April 26, 2004. Supersedes Version 1.0 ratified on July 5, 1997.

Debian, the producers of the Debian system, have created the Debian Social Contract. The Debian Free Software Guidelines (DFSG) part of the contract, initially designed as a set of commitments that we agree to abide by, has been adopted by the free software community as the basis of the Open Source Definition.

Social Contract with the Free Software Community

  1. Debian will remain 100% free

    We provide the guidelines that we use to determine if a work is free in the document entitled The Debian Free Software Guidelines. We promise that the Debian system and all its components will be free according to these guidelines. We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component.

  2. We will give back to the free software community

    When we write new components of the Debian system, we will license them in a manner consistent with the Debian Free Software Guidelines. We will make the best system we can, so that free works will be widely distributed and used. We will communicate things such as bug fixes, improvements and user requests to the upstream authors of works included in our system.

  3. We will not hide problems

    We will keep our entire bug report database open for public view at all times. Reports that people file online will promptly become visible to others.

  4. Our priorities are our users and free software

    We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system.

  5. Works that do not meet our free software standards

    We acknowledge that some of our users require the use of works that do not conform to the Debian Free Software Guidelines. We have created contrib and non-free areas in our archive for these works. The packages in these areas are not part of the Debian system, although they have been configured for use with Debian. We encourage CD manufacturers to read the licenses of the packages in these areas and determine if they can distribute the packages on their CDs. Thus, although non-free works are not a part of Debian, we support their use and provide infrastructure for non-free packages (such as our bug tracking system and mailing lists).

The Debian Free Software Guidelines (DFSG)

  1. Free Redistribution

    The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale.

  2. Source Code

    The program must include source code, and must allow distribution in source code as well as compiled form.

  3. Derived Works

    The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

  4. Integrity of The Author's Source Code

    The license may restrict source-code from being distributed in modified form _only_ if the license allows the distribution of patch files with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. (This is a compromise. The Debian group encourages all authors not to restrict any files, source or binary, from being modified.)

  5. No Discrimination Against Persons or Groups

    The license must not discriminate against any person or group of persons.

  6. No Discrimination Against Fields of Endeavor

    The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

  7. Distribution of License

    The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

  8. License Must Not Be Specific to Debian

    The rights attached to the program must not depend on the program's being part of a Debian system. If the program is extracted from Debian and used or distributed without Debian but otherwise within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the Debian system.

  9. License Must Not Contaminate Other Software

    The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be free software.

  10. Example Licenses

    The GPL, BSD, and Artistic licenses are examples of licenses that we consider free.

The concept of stating our social contract with the free software community was suggested by Ean Schuessler. This document was drafted by Bruce Perens, refined by the other Debian developers during a month-long e-mail conference in June 1997, and then \ accepted as the publicly stated policy of the Debian Project.

Bruce Perens later removed the Debian-specific references from the Debian Free Software Guidelines to create The Open Source Definition.

Other organizations may derive from and build on this document. Please give credit to the Debian project if you do.

doc-debian-6.1/doc/bug-log-mailserver.wml0000664000000000000000000001431412037617006015233 0ustar

Introduction to the bug system request server

There is a mailserver which can send the bug reports and indices as plain text on request.

To use it you send a mail message to request@bugs.debian.org. The Subject of the message is ignored, except for generating the Subject of the reply.

The body you send should be a series of commands, one per line. You'll receive a reply which looks like a transcript of your message being interpreted, with a response to each command. No notifications are sent to anyone for the commands listed here and the mail isn't logged anywhere publicly available.

Any text on a line starting with a hash sign # is ignored; the server will stop processing when it finds a line with a control terminator ( quit, thank you, or two hyphens are common examples). It will also stop if it encounters too many unrecognised or badly-formatted commands. If no commands are successfully handled it will send the help text for the server.

Commands available

send bugnumber
send-detail bugnumber
Requests the transcript for the bug report in question. send-detail sends all of the boring messages in the transcript as well, such as the various auto-acks.
index [full]
index-summary by-package
index-summary by-number
Request the full index (with full details, and including done and forwarded reports), or the summary sorted by package or by number, respectively.
index-maint
Requests the index page giving the list of maintainers with bugs (open and recently-closed) in the tracking system.
index maint maintainer
Requests the index pages of bugs in the system for the maintainer maintainer. The search term is an exact match. The bug index will be sent in a separate message.
index-packages
Requests the index page giving the list of packages with bugs (open and recently-closed) in the tracking system.
index packages package
Requests the index pages of bugs in the system for the package package. The search term is an exact match. The bug index will be sent in a separate message.
send-unmatched [this|0]
send-unmatched last|-1
send-unmatched old|-2
Requests logs of messages not matched to a particular bug report, for this week, last week and the week before. (Each week ends on a Wednesday.)
getinfo filename

Request a file containing information about package(s) and or maintainer(s) - the files available are:

maintainers
The unified list of packages' maintainers, as used by the tracking system. This is derived from information in the Packages files, override files and pseudo-packages files.
override.distribution
override.distribution.non-free
override.distribution.contrib
override.experimental
Information about the priorities and sections of packages and overriding values for the maintainers. This information is used by the process which generates the Packages files in the FTP archive. Information is available for each of the main distribution trees available, by their codewords.
pseudo-packages.description
pseudo-packages.maintainers
List of descriptions and maintainers respectively for pseudo-packages.
refcard
Requests that the mailservers' reference card be sent in plain ASCII.
help
Requests that this help document be sent by email in plain ASCII.
quit
stop
thank
thanks
thankyou
thank you
--
Stops processing at this point of the message. After this you may include any text you like, and it will be ignored. You can use this to include longer comments than are suitable for #, for example for the benefit of human readers of your message (reading it via the tracking system logs or due to a CC or BCC).
#...
One-line comment. The # must be at the start of the line.
debug level
Sets the debugging level to level, which should be a nonnegative integer. 0 is no debugging; 1 is usually sufficient. The debugging output appears in the transcript. It is not likely to be useful to general users of the bug system.

There is a reference card for the mailservers, available via the WWW, in bug-mailserver-refcard.txt or by email using the refcard command (see above).

If you wish to manipulate bug reports you should use the control@bugs.debian.org address, which understands a superset of the commands listed above. This is described in another document, available on the WWW, in the file bug-maint-mailcontrol.txt, or by sending help to control@bugs.

In case you are reading this as a plain text file or via email: an HTML version is available via the bug system main contents page http://www.debian.org/Bugs/.

doc-debian-6.1/doc/constitution.1.0.wml0000664000000000000000000007634312037617006014601 0ustar

Historical version of the Constitution for the Debian Project (v1.0)

Version 1.0 ratified on December 2nd, 1998. Superseded by Version 1.1 ratified on June 21st, 2003, which is itself superseded by version 1.2, ratified on October 29th, 2003. Version 1.2 was again superseded by version 1.3 ratified on September 24th, 2006. That was superseded by the current version ratified on October 7th, 2007.

1. Introduction

The Debian Project is an association of individuals who have made common cause to create a free operating system.

This document describes the organisational structure for formal decision-making in the Project. It does not describe the goals of the Project or how it achieves them, or contain any policies except those directly related to the decision-making process.

2. Decision-making bodies and individuals

Each decision in the Project is made by one or more of the following:

  1. The Developers, by way of General Resolution or an election;
  2. The Project Leader;
  3. The Technical Committee and/or its Chairman;
  4. The individual Developer working on a particular task;
  5. Delegates appointed by the Project Leader for specific tasks;
  6. The Project Secretary.

Most of the remainder of this document will outline the powers of these bodies, their composition and appointment, and the procedure for their decision-making. The powers of a person or body may be subject to review and/or limitation by others; in this case the reviewing body or person's entry will state this. In the list above, a person or body is usually listed before any people or bodies whose decisions they can overrule or who they (help) appoint - but not everyone listed earlier can overrule everyone listed later.

2.1. General rules

  1. Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them.

  2. A person may hold several posts, except that the Project Leader, Project Secretary and the Chairman of the Technical Committee must be distinct, and that the Leader cannot appoint themselves as their own Delegate.

  3. A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly.

3. Individual Developers

3.1. Powers

An individual Developer may

  1. make any technical or nontechnical decision with regard to their own work;
  2. propose or sponsor draft General Resolutions;
  3. propose themselves as a Project Leader candidate in elections;
  4. vote on General Resolutions and in Leadership elections.

3.2. Composition and appointment

  1. Developers are volunteers who agree to further the aims of the Project insofar as they participate in it, and who maintain package(s) for the Project or do other work which the Project Leader's Delegate(s) consider worthwhile.

  2. The Project Leader's Delegate(s) may choose not to admit new Developers, or expel existing Developers. If the Developers feel that the Delegates are abusing their authority they can of course override the decision by way of General Resolution - see §4.1(3), §4.2.

3.3. Procedure

Developers may make these decisions as they see fit.

4. The Developers by way of General Resolution or election

4.1. Powers

Together, the Developers may:

  1. Appoint or recall the Project Leader.

  2. Amend this constitution, provided they agree with a 3:1 majority.

  3. Override any decision by the Project Leader or a Delegate.

  4. Override any decision by the Technical Committee, provided they agree with a 2:1 majority.

  5. Issue nontechnical policy documents and statements.

    These include documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software licence terms that Debian software must meet.

    They may also include position statements about issues of the day.

  6. Together with the Project Leader and SPI, make decisions about property held in trust for purposes related to Debian. (See §9.1.)

4.2. Procedure

  1. The Developers follow the Standard Resolution Procedure, below. A resolution or amendment is introduced if proposed by any Developer and sponsored by at least K other Developers, or if proposed by the Project Leader or the Technical Committee.

  2. Delaying a decision by the Project Leader or their Delegate:

    1. If the Project Leader or their Delegate, or the Technical Committee, has made a decision, then Developers can override them by passing a resolution to do so; see §4.1(3).
    2. If such a resolution is sponsored by at least 2K Developers, or if it is proposed by the Technical Committee, the resolution puts the decision immediately on hold (provided that resolution itself says so).
    3. If the original decision was to change a discussion period or a voting period, or the resolution is to override the Technical Committee, then only K Developers need to sponsor the resolution to be able to put the decision immediately on hold.
    4. If the decision is put on hold, an immediate vote is held to determine whether the decision will stand until the full vote on the decision is made or whether the implementation of the original decision will be delayed until then. There is no quorum for this immediate procedural vote.
    5. If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted.

  3. Votes are taken by the Project Secretary. Votes and tallies results are not be revealed during the voting period; after the vote the Project Secretary lists all the votes cast. The voting period is 2 weeks, but may be varied by up to 1 week by the Project Leader, and may be ended by the Project Secretary when the outcome of a vote is no longer in doubt.

  4. The minimum discussion period is 2 weeks, but may be varied by up to 1 week by the Project Leader. The Project Leader has a casting vote. There is a quorum of 3Q.

  5. Proposals, sponsors, amendments, calls for votes and other formal actions are made by announcement on a publicly-readable electronic mailing list designated by the Project Leader's Delegate(s); any Developer may post there.

  6. Votes are cast by email in a manner suitable to the Secretary. The Secretary determines for each poll whether voters can change their votes.

  7. Q is half of the square root of the number of current Developers. K is Q or 5, whichever is the smaller. Q and K need not be integers and are not rounded.

5. Project Leader

5.1. Powers

The Project Leader may:

  1. Appoint Delegates or delegate decisions to the Technical Committee.

    The Leader may define an area of ongoing responsibility or a specific decision and hand it over to another Developer or to the Technical Committee.

    Once a particular decision has been delegated and made the Project Leader may not withdraw that delegation; however, they may withdraw an ongoing delegation of particular area of responsibility.

  2. Lend authority to other Developers.

    The Project Leader may make statements of support for points of view or for other members of the project, when asked or otherwise; these statements have force if and only if the Leader would be empowered to make the decision in question.

  3. Make any decision which requires urgent action.

    This does not apply to decisions which have only become gradually urgent through lack of relevant action, unless there is a fixed deadline.

  4. Make any decision for whom noone else has responsibility.

  5. Propose draft General Resolutions and amendments.

  6. Together with the Technical Committee, appoint new members to the Committee. (See §6.2.)

  7. Use a casting vote when Developers vote.

    The Project Leader also has a normal vote in such ballots.

  8. Vary the discussion period for Developers' votes (as above).

  9. Lead discussions amongst Developers.

    The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand. The Project Leader should not use the Leadership position to promote their own personal views.

  10. Together with SPI, make decisions affecting property held in trust for purposes related to Debian. (See §9.1.)

5.2. Appointment

  1. The Project Leader is elected by the Developers.
  2. The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately.
  3. For the following three weeks any Developer may nominate themselves as a candidate Project Leader.
  4. For three weeks after that no more candidates may be nominated; candidates should use this time for campaigning (to make their identities and positions known). If there are no candidates at the end of the nomination period then the nomination period is extended for three further weeks, repeatedly if necessary.
  5. The next three weeks are the polling period during which Developers may cast their votes. Votes in leadership elections are kept secret, even after the election is finished.
  6. The options on the ballot will be those candidates who have nominated themselves and have not yet withdrawn, plus None Of The Above. If None Of The Above wins the election then the election procedure is repeated, many times if necessary.
  7. The decision will be made using Concorde Vote Counting. The quorum is the same as for a General Resolution (§4.2) and the default option is None Of The Above.
  8. The Project Leader serves for one year from their election.

5.3. Procedure

The Project Leader should attempt to make decisions which are consistent with the consensus of the opinions of the Developers.

Where practical the Project Leader should informally solicit the views of the Developers.

The Project Leader should avoid overemphasizing their own point of view when making decisions in their capacity as Leader.

6. Technical committee

6.1. Powers

The Technical Committee may:

  1. Decide on any matter of technical policy.

    This includes the contents of the technical policy manuals, developers' reference materials, example packages and the behaviour of non-experimental package building tools. (In each case the usual maintainer of the relevant software or documentation makes decisions initially, however; see 6.3(5).)

  2. Decide any technical matter where Developers' jurisdictions overlap.

    In cases where Developers need to implement compatible technical policies or stances (for example, if they disagree about the priorities of conflicting packages, or about ownership of a command name, or about which package is responsible for a bug that both maintainers agree is a bug, or about who should be the maintainer for a package) the technical committee may decide the matter.

  3. Make a decision when asked to do so.

    Any person or body may delegate a decision of their own to the Technical Committee, or seek advice from it.

  4. Overrule a Developer (requires a 3:1 majority).

    The Technical Committee may ask a Developer to take a particular technical course of action even if the Developer does not wish to; this requires a 3:1 majority. For example, the Committee may determine that a complaint made by the submitter of a bug is justified and that the submitter's proposed solution should be implemented.

  5. Offer advice.

    The Technical Committee may make formal announcements about its views on any matter. Individual members may of course make informal statements about their views and about the likely views of the committee.

  6. Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.)

  7. Appoint the Chairman of the Technical Committee.

    The Chairman is elected by the Committee from its members. All members of the committee are automatically nominated; the committee vote starting one week before the post will become vacant (or immediately, if it is already too late). The members may vote by public acclamation for any fellow committee member, including themselves; there is no None Of The Above option. The vote finishes when all the members have voted or when the outcome is no longer in doubt. The result is determined according to Concorde Vote Counting.

  8. The Chairman can stand in for the Leader, together with the Secretary

    As detailed in §7.1(2), the Chairman of the Technical Committee and the Project Secretary may together stand in for the Leader if there is no Leader.

6.2. Composition

  1. The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members.

  2. When there are fewer than 8 members the Technical Committee may recommend new member(s) to the Project Leader, who may choose (individually) to appoint them or not.

  3. When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6.

  4. When there have been 5 members or fewer for at least one week the Project Leader may appoint new member(s) until the number of members reaches 6, at intervals of at least one week per appointment.

  5. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee.

6.3. Procedure

  1. The Technical Committee uses the Standard Resolution Procedure.

    A draft resolution or amendment may be proposed by any member of the Technical Committee. There is no minimum discussion period; the voting period lasts for up to one week, or until the outcome is no longer in doubt. Members may change their votes. There is a quorum of two.

  2. Details regarding voting

    The Chairman has a casting vote. When the Technical Committee votes whether to override a Developer who also happens to be a member of the Committee, that member may not vote (unless they are the Chairman, in which case they may use only their casting vote).

  3. Public discussion and decision-making.

    Discussion, draft resolutions and amendments, and votes by members of the committee, are made public on the Technical Committee public discussion list. There is no separate secretary for the Committee.

  4. Confidentiality of appointments.

    The Technical Committee may hold confidential discussions via private email or a private mailing list or other means to discuss appointments to the Committee. However, votes on appointments must be public.

  5. No detailed design work.

    The Technical Committee does not engage in design of new proposals and policies. Such design work should be carried out by individuals privately or together and discussed in ordinary technical policy and design forums.

    The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere.

    Individual members of the technical committee may of course participate on their own behalf in any aspect of design and policy work.

  6. Technical Committee makes decisions only as last resort.

    The Technical Committee does not make a technical decision until efforts to resolve it via consensus have been tried and failed, unless it has been asked to make a decision by the person or body who would normally be responsible for it.

7. The Project Secretary

7.1. Powers

The Secretary:

  1. Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution.

  2. Can stand in for the Leader, together with the Chairman of the Technical Committee.

    If there is no Project Leader then the Chairman of the Technical Committee and the Project Secretary may by joint agreement make decisions if they consider it imperative to do so.

  3. Adjudicates any disputes about interpretation of the constitution.

  4. May delegate part or all of their authority to someone else, or withdraw such a delegation at any time.

7.2. Appointment

The Project Secretary is appointed by the Project Leader and the current Project Secretary.

If the Project Leader and the current Project Secretary cannot agree on a new appointment they must ask the board of SPI (see §9.1.) to appoint a Secretary.

If there is no Project Secretary or the current Secretary is unavailable and has not delegated authority for a decision then the decision may be made or delegated by the Chairman of the Technical Committee, as Acting Secretary.

The Project Secretary's term of office is 1 year, at which point they or another Secretary must be (re)appointed.

7.3. Procedure

The Project Secretary should make decisions which are fair and reasonable, and preferably consistent with the consensus of the Developers.

When acting together to stand in for an absent Project Leader the Chairman of the Technical Committee and the Project Secretary should make decisions only when absolutely necessary and only when consistent with the consensus of the Developers.

8. The Project Leader's Delegates

8.1. Powers

The Project Leader's Delegates:

  1. have powers delegated to them by the Project Leader;
  2. may make certain decisions which the Leader may not make directly, including approving or expelling Developers or designating people as Developers who do not maintain packages. This is to avoid concentration of power, particularly over membership as a Developer, in the hands of the Project Leader.

8.2. Appointment

The Delegates are appointed by the Project Leader and may be replaced by the Leader at the Leader's discretion. The Project Leader may not make the position as a Delegate conditional on particular decisions by the Delegate, nor may they override a decision made by a Delegate once made.

8.3. Procedure

Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion.

9. Software in the Public Interest

SPI and Debian are separate organisations who share some goals. Debian is grateful for the legal support framework offered by SPI. Debian's Developers are currently members of SPI by virtue of their status as Developers.

9.1. Authority

  1. SPI has no authority regarding Debian's technical or nontechnical decisions, except that no decision by Debian with respect to any property held by SPI shall require SPI to act outside its legal authority, and that Debian's constitution may occasionally use SPI as a decision body of last resort.
  2. Debian claims no authority over SPI other than that over the use of certain of SPI's property, as described below, though Debian Developers may be granted authority within SPI by SPI's rules.
  3. Debian Developers are not agents or employees of SPI, or of each other or of persons in authority in the Debian Project. A person acting as a Developer does so as an individual, on their own behalf.

9.2. Management of property for purposes related to Debian

Since Debian has no authority to hold money or property, any donations for the Debian Project must be made to SPI, which manages such affairs.

SPI have made the following undertakings:

  1. SPI will hold money, trademarks and other tangible and intangible property and manage other affairs for purposes related to Debian.
  2. Such property will be accounted for separately and held in trust for those purposes, decided on by Debian and SPI according to this section.
  3. SPI will not dispose of or use property held in trust for Debian without approval from Debian, which may be granted by the Project Leader or by General Resolution of the Developers.
  4. SPI will consider using or disposing of property held in trust for Debian when asked to do so by the Project Leader.
  5. SPI will use or dispose of property held in trust for Debian when asked to do so by a General Resolution of the Developers, provided that this is compatible with SPI's legal authority.
  6. SPI will notify the Developers by electronic mail to a Debian Project mailing list when it uses or disposes of property held in trust for Debian.

A. Standard Resolution Procedure

These rules apply to communal decision-making by committees and plebiscites, where stated above.

A.1. Proposal

The formal procedure begins when a draft resolution is proposed and sponsored, as required.

A.1. Discussion and Amendment

  1. Following the proposal, the resolution may be discussed. Amendments may be made formal by being proposed and sponsored according to the requirements for a new resolution, or directly by the proposer of the original resolution.
  2. A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match.
  3. If a formal amendment is not accepted, or one of the sponsors of the resolution does not agree with the acceptance by the proposer of a formal amendment, the amendment remains as an amendment and will be voted on.
  4. If an amendment accepted by the original proposer is not to the liking of others, they may propose another amendment to reverse the earlier change (again, they must meet the requirements for proposer and sponsor(s).)
  5. The proposer of a resolution may suggest changes to the wordings of amendments; these take effect if the proposer of the amendment agrees and none of the sponsors object. In this case the changed amendments will be voted on instead of the originals.
  6. The proposer of a resolution may make changes to correct minor errors (for example, typographical errors or inconsistencies) or changes which do not alter the meaning, providing noone objects within 24 hours. In this case the minimum discussion period is not restarted.

A.2. Calling for a vote

  1. The proposer or a sponsor of a motion or an amendment may call for a vote, providing that the minimum discussion period (if any) has elapsed.
  2. The proposer or a sponsor of a motion may call for a vote on any or all of the amendments individually or together; the proposer or sponsor of an amendment may call for a vote only on that amendment and related amendments.
  3. The person who calls for a vote states what they believe the wordings of the resolution and any relevant amendments are, and consequently what form the ballot should take. However, the final decision on the form of ballot(s) is the Secretary's - see 7.1(1), 7.1(3) and A.3(6).
  4. The minimum discussion period is counted from the time the last formal amendment was accepted, or the last related formal amendment was accepted if an amendment is being voted on, or since the whole resolution was proposed if no amendments have been proposed and accepted.

A.3. Voting procedure

  1. Each independent set of related amendments is voted on in a separate ballot. Each such ballot has as options all the sensible combinations of amendments and options, and an option Further Discussion. If Further Discussion wins then the entire resolution procedure is set back to the start of the discussion period. No quorum is required for an amendment.
  2. When the final form of the resolution has been determined it is voted on in a final ballot, in which the options are Yes, No and Further Discussion. If Further Discussion wins then the entire procedure is set back to the start of the discussion period.
  3. The vote taker (if there is one) or the voters (if voting is done by public pronouncement) may arrange for these ballots to be held simultaneously, even (for example) using a single voting message. If amendment ballot(s) and the final ballot are combined in this way then it must be possible for a voter to vote differently in the final ballot for each of the possible forms of the final draft resolution.
  4. Votes may be cast during the voting period, as specified elsewhere. If the voting period can end if the outcome is no longer in doubt, the possibility that voters may change their votes is not considered.
  5. The votes are counted according to the Concorde Vote Counting. If a quorum is required then the default option is Further Discussion.
  6. In cases of doubt the Project Secretary shall decide on matters of procedure (for example, whether particular amendments should be considered independent or not).

A.4. Withdrawing resolutions or unaccepted amendments

The proposer of a resolution or unaccepted amendment may withdraw it. In this case new proposers may come forward keep it alive, in which case the first person to do so becomes the new proposer and any others become sponsors if they aren't sponsors already.

A sponsor of a resolution or amendment (unless it has been accepted) may withdraw.

If the withdrawal of the proposer and/or sponsors means that a resolution has no proposer or not enough sponsors it will not be voted on unless this is rectified before the resolution expires.

A.5. Expiry

If a proposed resolution has not been discussed, amended, voted on or otherwise dealt with for 4 weeks then it is considered to have been withdrawn.

A.6. Concorde Vote Counting

  1. This is used to determine the winner amongst a list of options. Each ballot paper gives a ranking of the voter's preferred options. (The ranking need not be complete.)
  2. Option A is said to Dominate option B if strictly more ballots prefer A to B than prefer B to A.
  3. All options which are Dominated by at least one other option are discarded, and references to them in ballot papers will be ignored.
  4. If there is any option which Dominates all others then that is the winner.
  5. If there is now more than one option remaining Single Transferrable Vote will be applied to choose amongst those remaining:
    • The number of first preferences for each option is counted, and if any option has more than half it is the winner.
    • Otherwise the option with the lowest number of first preferences is eliminated and its votes redistributed according to the second preferences.
    • This elimination procedure is repeated, moving down ballot papers to 2nd, 3rd, 4th, etc. preferences as required, until one option gets more than half of the first preferences.
  6. In the case of ties the elector with a casting vote will decide. The casting vote does not count as a normal vote; however that elector will usually also get a normal vote.
  7. If a supermajority is required the number of Yes votes in the final ballot is reduced by an appropriate factor. Strictly speaking, for a supermajority of F:A, the number of ballots which prefer Yes to X (when considering whether Yes Dominates X or X Dominates Yes) or the number of ballots whose first (remaining) preference is Yes (when doing STV comparisons for winner and elimination purposes) is multiplied by a factor A/F before the comparison is done. This means that a 2:1 vote, for example, means twice as many people voted for as against; abstentions are not counted.
  8. If a quorum is required, there must be at least that many votes which prefer the winning option to the default option. If there are not then the default option wins after all. For votes requiring a supermajority, the actual number of Yes votes is used when checking whether the quorum has been reached.

When the Standard Resolution Procedure is to be used, the text which refers to it must specify what is sufficient to have a draft resolution proposed and/or sponsored, what the minimum discussion period is, and what the voting period is. It must also specify any supermajority and/or the quorum (and default option) to be used.

B. Use of language and typography

The present indicative (is, for example) means that the statement is a rule in this constitution. May or can indicates that the person or body has discretion. Should means that it would be considered a good thing if the sentence were obeyed, but it is not binding. Text marked as a citation, such as this, is rationale and does not form part of the constitution. It may be used only to aid interpretation in cases of doubt.

doc-debian-6.1/doc/source-unpack.txt0000664000000000000000000000504011742247066014332 0ustar HOW TO UNPACK A DEBIAN SOURCE PACKAGE If you have `dpkg-source', you can use it to unpack any Debian source package: put all the files in the same directory and type `dpkg-source -x .dsc'. The remainder of this document explains how to unpack Debian source packages on non-Debian systems, or on Debian systems without the `dpkg-dev' package installed. There are several kinds of Debian source packages, identified by the Format: field in the .dsc file. If there is no Format: field, treat it as "1.0". "1.0" packages can be either native or non-native. Native packages (where the Debian source is the upstream source) look like this: hello_1.3.dsc hello_1.3.tar.gz To unpack this kind of package, just untar the .tar.gz file. Non-native "1.0" packages look like this: hello_1.3-11.dsc hello_1.3-11.diff.gz hello_1.3.orig.tar.gz - note the `.orig' part 1. untar P_V.orig.tar.gz. 2. rename the resulting P-V.orig directory to P-V. If some other directory results, rename *it* to P-V. 3. mkdir P-V/debian. 4. apply the diff with patch -p0. 5. do `chmod +x P-V/debian/rules' (where P is the package name and V the upstream version - `hello' and `1.3' respectively in this example.) "3.0 (native)" packages are the same as native "1.0" packages, except that the source tarball may be compressed using methods other than gzip. "3.0 (quilt)" packages look like this: hello_1.3-11.dsc hello_1.3-11.debian.tar.gz hello_1.3.orig.tar.gz hello_1.3.orig-COMPONENT.tar.gz (optional, for one or more values of COMPONENT) The compressed files may be compressed using methods other than gzip. To unpack this kind of package, you will need to install `quilt' (http://savannah.nongnu.org/projects/quilt), then: 1. untar P_V.orig.tar.gz. 2. rename the resulting P-V.orig directory to P-V. If some other directory results, rename *it* to P-V. 3. if there are any orig-COMPONENT tarballs, untar each of them to P-V/COMPONENT. 4. remove P-V/debian if it exists. 5. change to the P-V directory. 6. untar P_V-R.debian.tar.gz; it will unpack to a `debian' subdirectory. 7. run `QUILT_PATCHES=debian/patches quilt push -a'. (where P is the package name, V the upstream version, and R the Debian revision - `hello', `1.3', and `11' in this example.) See the dpkg-source(1) manual page for full details of all formats, including experimental ones. -- Ian Jackson Sat, 31 Aug 1996 -- Colin Watson Sun, 17 Oct 2010 doc-debian-6.1/doc/debian-manifesto0000664000000000000000000001557611003202402014130 0ustar Please note that this document is provided in order to document Debian's history. While the general ideas still apply some details changed. ******************** Appendix The Debian Manifesto ******************** The Debian Linux Manifesto Written by Ian A. Murdock Revised 01/06/94 What is Debian Linux? ===================== Debian Linux is a brand-new kind of Linux distribution. Rather than being developed by one isolated individual or group, as other distributions of Linux have been developed in the past, Debian is being developed openly in the spirit of Linux and GNU. The primary purpose of the Debian project is to finally create a distribution that lives up to the Linux name. Debian is being carefully and conscientiously put together and will be maintained and supported with similar care. It is also an attempt to create a non-commercial distribution that will be able to effectively compete in the commercial market. It will eventually be distributed by The Free Software Foundation on CD-ROM, and The Debian Linux Association will offer the distribution on floppy disk and tape along with printed manuals, technical support and other end-user essentials. All of the above will be available at little more than cost, and the excess will be put toward further development of free software for all users. Such distribution is essential to the success of the Linux operating system in the commercial market, and it must be done by organizations in a position to successfully advance and advocate free software without the pressure of profits or returns. Why is Debian being constructed? ================================ Distributions are essential to the future of Linux. Essentially, they eliminate the need for the user to locate, download, compile, install and integrate a fairly large number of essential tools to assemble a working Linux system. Instead, the burden of system construction is placed on the distribution creator, whose work can be shared with thousands of other users. Almost all users of Linux will get their first taste of it through a distribution, and most users will continue to use a distribution for the sake of convenience even after they are familiar with the operating system. Thus, distributions play a very important role indeed. Despite their obvious importance, distributions have attracted little attention from developers. There is a simple reason for this: they are neither easy nor glamorous to construct and require a great deal of ongoing effort from the creator to keep the distribution bug-free and up-to-date. It is one thing to put together a system from scratch; it is quite another to ensure that the system is easy for others to install, is installable and usable under a wide variety of hardware configurations, contains software that others will find useful, and is updated when the components themselves are improved. Many distributions have started out as fairly good systems, but as time passes attention to maintaining the distribution becomes a secondary concern. A case-in-point is the Softlanding Linux System (better known as SLS). It is quite possibly the most bug-ridden and badly maintained Linux distribution available; unfortunately, it is also quite possibly the most popular. It is, without question, the distribution that attracts the most attention from the many commercial "distributors" of Linux that have surfaced to capitalize on the growing popularity of the operating system. This is a bad combination indeed, as most people who obtain Linux from these "distributors" receive a bug-ridden and badly maintained Linux distribution. As if this wasn't bad enough, these "distributors" have a disturbing tendency to misleadingly advertise non-functional or extremely unstable "features" of their product. Combine this with the fact that the buyers will, of course, expect the product to live up to its advertisement and the fact that many may believe it to be a commercial operating system (there is also a tendency not to mention that Linux is free nor that it is distributed under the GNU General Public License). To top it all off, these "distributors" are actually making enough money from their effort to justify buying larger advertisements in more magazines; it is the classic example of unacceptable behavior being rewarded by those who simply do not know any better. Clearly something needs to be done to remedy the situation. How will Debian attempt to put an end to these problems? ======================================================== The Debian design process is open to ensure that the system is of the highest quality and that it reflects the needs of the user community. By involving others with a wide range of abilities and backgrounds, Debian is able to be developed in a modular fashion. Its components are of high quality because those with expertise in a certain area are given the opportunity to construct or maintain the individual components of Debian involving that area. Involving others also ensures that valuable suggestions for improvement can be incorporated into the distribution during its development; thus, a distribution is created based on the needs and wants of the users rather than the needs and wants of the constructor. It is very difficult for one individual or small group to anticipate these needs and wants in advance without direct input from others. Debian Linux will also be distributed on physical media by the Free Software Foundation and the Debian Linux Association. This provides Debian to users without access to the Internet or FTP and additionally makes products and services such as printed manuals and technical support available to all users of the system. In this way, Debian may be used by many more individuals and organizations than is otherwise possible, the focus will be on providing a first-class product and not on profits or returns, and the margin from the products and services provided may be used to improve the software itself for all users whether they paid to obtain it or not. The Free Software Foundation plays an extremely important role in the future of Debian. By the simple fact that they will be distributing it, a message is sent to the world that Linux is not a commercial product and that it never should be, but that this does not mean that Linux will never be able to compete commercially. For those of you who disagree, I challenge you to rationalize the success of GNU Emacs and GCC, which are not commercial software but which have had quite an impact on the commercial market regardless of that fact. The time has come to concentrate on the future of Linux rather than on the destructive goal of enriching oneself at the expense of the entire Linux community and its future. The development and distribution of Debian may not be the answer to the problems that I have outlined in the Manifesto, but I hope that it will at least attract enough attention to these problems to allow them to be solved. doc-debian-6.1/doc/bug-log-access.wml0000664000000000000000000000427012037617526014332 0ustar

Methods of accessing the bug tracking system logs

Accessing active bug reports

Each message received at or sent by the bug processing system is logged and made available in a number of ways.

The primary access method is to use the web pages. See the forms on the main BTS page at http://bugs.debian.org/

There is a mailserver which can send bug reports as plain text on request. To use it send the word help as the sole contents of an email to request@bugs.debian.org (the Subject of the message is ignored), or read the instructions on the World Wide Web or in the file bug-log-mailserver.txt.

Accessing archived bug reports

Each closed bug report is archived 28 days after the last message relating to it is received and filed. This means that it is no longer possible to access it or change anything about it using the control and service bots. However, the reports are still accessible for viewing.

You can search the bug report archive using the WWW forms at http://bugs.debian.org/, simply select the archived bugs option.

Note that it doesn't contain the oldest closed bug reports, only those after #40000, approximately.

Accessing the raw bug data

If you need to get hold of the raw data used by the bug tracking system, you can mirror it using rsync from bugs-mirror.debian.org. The relevant modules are bts-spool-db (for the active bug spool), bts-spool-archive (for bugs that have been closed for a while and thus archived), and bts-spool-index (for the bug index files).

At the time of writing, the active spool is about 2.5GB and the archived spool is about 10GB. If you only need a sample for testing purposes, please consider downloading only part of the active spool rather than the whole thing.

Please do not rely on *.status files in the bug spools, as they are obsolete, for compatibility purposes only, and will be removed at some point in the future. Use the *.summary files instead.

doc-debian-6.1/doc/constitution.wml0000664000000000000000000010260312037617006014271 0ustar

Constitution for the Debian Project (v1.4)

Version 1.4 ratified on October 7th, 2007. Supersedes Version 1.3 ratified on September 24th, 2006, Version 1.2 ratified on October 29th, 2003 and Version 1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 ratified on December 2nd, 1998.

1. Introduction

The Debian Project is an association of individuals who have made common cause to create a free operating system.

This document describes the organisational structure for formal decision-making in the Project. It does not describe the goals of the Project or how it achieves them, or contain any policies except those directly related to the decision-making process.

2. Decision-making bodies and individuals

Each decision in the Project is made by one or more of the following:

  1. The Developers, by way of General Resolution or an election;
  2. The Project Leader;
  3. The Technical Committee and/or its Chairman;
  4. The individual Developer working on a particular task;
  5. Delegates appointed by the Project Leader for specific tasks;
  6. The Project Secretary.

Most of the remainder of this document will outline the powers of these bodies, their composition and appointment, and the procedure for their decision-making. The powers of a person or body may be subject to review and/or limitation by others; in this case the reviewing body or person's entry will state this. In the list above, a person or body is usually listed before any people or bodies whose decisions they can overrule or who they (help) appoint - but not everyone listed earlier can overrule everyone listed later.

2.1. General rules

  1. Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them.

  2. A person may hold several posts, except that the Project Leader, Project Secretary and the Chairman of the Technical Committee must be distinct, and that the Leader cannot appoint themselves as their own Delegate.

  3. A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly.

3. Individual Developers

3.1. Powers

An individual Developer may

  1. make any technical or nontechnical decision with regard to their own work;
  2. propose or sponsor draft General Resolutions;
  3. propose themselves as a Project Leader candidate in elections;
  4. vote on General Resolutions and in Leadership elections.

3.2. Composition and appointment

  1. Developers are volunteers who agree to further the aims of the Project insofar as they participate in it, and who maintain package(s) for the Project or do other work which the Project Leader's Delegate(s) consider worthwhile.

  2. The Project Leader's Delegate(s) may choose not to admit new Developers, or expel existing Developers. If the Developers feel that the Delegates are abusing their authority they can of course override the decision by way of General Resolution - see §4.1(3), §4.2.

3.3. Procedure

Developers may make these decisions as they see fit.

4. The Developers by way of General Resolution or election

4.1. Powers

Together, the Developers may:

  1. Appoint or recall the Project Leader.

  2. Amend this constitution, provided they agree with a 3:1 majority.

  3. Make or override any decision authorised by the powers of the Project Leader or a Delegate.

  4. Make or override any decision authorised by the powers of the Technical Committee, provided they agree with a 2:1 majority.

  5. Issue, supersede and withdraw nontechnical policy documents and statements.

    These include documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software licence terms that Debian software must meet.

    They may also include position statements about issues of the day.

    1. A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes.
    2. The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines.
    3. A Foundation Document requires a 3:1 majority for its supersession. New Foundation Documents are issued and existing ones withdrawn by amending the list of Foundation Documents in this constitution.

  6. Make decisions about property held in trust for purposes related to Debian. (See §9.).

  7. In case of a disagreement between the project leader and the incumbent secretary, appoint a new secretary.

4.2. Procedure

  1. The Developers follow the Standard Resolution Procedure, below. A resolution or amendment is introduced if proposed by any Developer and sponsored by at least K other Developers, or if proposed by the Project Leader or the Technical Committee.

  2. Delaying a decision by the Project Leader or their Delegate:

    1. If the Project Leader or their Delegate, or the Technical Committee, has made a decision, then Developers can override them by passing a resolution to do so; see §4.1(3).
    2. If such a resolution is sponsored by at least 2K Developers, or if it is proposed by the Technical Committee, the resolution puts the decision immediately on hold (provided that resolution itself says so).
    3. If the original decision was to change a discussion period or a voting period, or the resolution is to override the Technical Committee, then only K Developers need to sponsor the resolution to be able to put the decision immediately on hold.
    4. If the decision is put on hold, an immediate vote is held to determine whether the decision will stand until the full vote on the decision is made or whether the implementation of the original decision will be delayed until then. There is no quorum for this immediate procedural vote.
    5. If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted.

  3. Votes are taken by the Project Secretary. Votes, tallies, and results are not revealed during the voting period; after the vote the Project Secretary lists all the votes cast. The voting period is 2 weeks, but may be varied by up to 1 week by the Project Leader.

  4. The minimum discussion period is 2 weeks, but may be varied by up to 1 week by the Project Leader. The Project Leader has a casting vote. There is a quorum of 3Q.

  5. Proposals, sponsors, amendments, calls for votes and other formal actions are made by announcement on a publicly-readable electronic mailing list designated by the Project Leader's Delegate(s); any Developer may post there.

  6. Votes are cast by email in a manner suitable to the Secretary. The Secretary determines for each poll whether voters can change their votes.

  7. Q is half of the square root of the number of current Developers. K is Q or 5, whichever is the smaller. Q and K need not be integers and are not rounded.

5. Project Leader

5.1. Powers

The Project Leader may:

  1. Appoint Delegates or delegate decisions to the Technical Committee.

    The Leader may define an area of ongoing responsibility or a specific decision and hand it over to another Developer or to the Technical Committee.

    Once a particular decision has been delegated and made the Project Leader may not withdraw that delegation; however, they may withdraw an ongoing delegation of particular area of responsibility.

  2. Lend authority to other Developers.

    The Project Leader may make statements of support for points of view or for other members of the project, when asked or otherwise; these statements have force if and only if the Leader would be empowered to make the decision in question.

  3. Make any decision which requires urgent action.

    This does not apply to decisions which have only become gradually urgent through lack of relevant action, unless there is a fixed deadline.

  4. Make any decision for whom noone else has responsibility.

  5. Propose draft General Resolutions and amendments.

  6. Together with the Technical Committee, appoint new members to the Committee. (See §6.2.)

  7. Use a casting vote when Developers vote.

    The Project Leader also has a normal vote in such ballots.

  8. Vary the discussion period for Developers' votes (as above).

  9. Lead discussions amongst Developers.

    The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand. The Project Leader should not use the Leadership position to promote their own personal views.

  10. In consultation with the developers, make decisions affecting property held in trust for purposes related to Debian. (See §9.). Such decisions are communicated to the members by the Project Leader or their Delegate(s). Major expenditures should be proposed and debated on the mailing list before funds are disbursed.

  11. Add or remove organizations from the list of trusted organizations (see §9.3) that are authorized to accept and hold assets for Debian. The evaluation and discussion leading up to such a decision occurs on an electronic mailing list designated by the Project Leader or their Delegate(s), on which any developer may post. There is a minimum discussion period of two weeks before an organization may be added to the list of trusted organizations.

5.2. Appointment

  1. The Project Leader is elected by the Developers.
  2. The election begins six weeks before the leadership post becomes vacant, or (if it is too late already) immediately.
  3. For the first week any Developer may nominate themselves as a candidate Project Leader, and summarize their plans for their term.
  4. For three weeks after that no more candidates may be nominated; candidates should use this time for campaigning and discussion. If there are no candidates at the end of the nomination period then the nomination period is extended for an additional week, repeatedly if necessary.
  5. The next two weeks are the polling period during which Developers may cast their votes. Votes in leadership elections are kept secret, even after the election is finished.
  6. The options on the ballot will be those candidates who have nominated themselves and have not yet withdrawn, plus None Of The Above. If None Of The Above wins the election then the election procedure is repeated, many times if necessary.
  7. The decision will be made using the method specified in section §A.6 of the Standard Resolution Procedure. The quorum is the same as for a General Resolution (§4.2) and the default option is None Of The Above.
  8. The Project Leader serves for one year from their election.

5.3. Procedure

The Project Leader should attempt to make decisions which are consistent with the consensus of the opinions of the Developers.

Where practical the Project Leader should informally solicit the views of the Developers.

The Project Leader should avoid overemphasizing their own point of view when making decisions in their capacity as Leader.

6. Technical committee

6.1. Powers

The Technical Committee may:

  1. Decide on any matter of technical policy.

    This includes the contents of the technical policy manuals, developers' reference materials, example packages and the behaviour of non-experimental package building tools. (In each case the usual maintainer of the relevant software or documentation makes decisions initially, however; see 6.3(5).)

  2. Decide any technical matter where Developers' jurisdictions overlap.

    In cases where Developers need to implement compatible technical policies or stances (for example, if they disagree about the priorities of conflicting packages, or about ownership of a command name, or about which package is responsible for a bug that both maintainers agree is a bug, or about who should be the maintainer for a package) the technical committee may decide the matter.

  3. Make a decision when asked to do so.

    Any person or body may delegate a decision of their own to the Technical Committee, or seek advice from it.

  4. Overrule a Developer (requires a 3:1 majority).

    The Technical Committee may ask a Developer to take a particular technical course of action even if the Developer does not wish to; this requires a 3:1 majority. For example, the Committee may determine that a complaint made by the submitter of a bug is justified and that the submitter's proposed solution should be implemented.

  5. Offer advice.

    The Technical Committee may make formal announcements about its views on any matter. Individual members may of course make informal statements about their views and about the likely views of the committee.

  6. Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.)

  7. Appoint the Chairman of the Technical Committee.

    The Chairman is elected by the Committee from its members. All members of the committee are automatically nominated; the committee votes starting one week before the post will become vacant (or immediately, if it is already too late). The members may vote by public acclamation for any fellow committee member, including themselves; there is no default option. The vote finishes when all the members have voted, or when the voting period has ended. The result is determined using the method specified in section A.6 of the Standard Resolution Procedure.

  8. The Chairman can stand in for the Leader, together with the Secretary

    As detailed in §7.1(2), the Chairman of the Technical Committee and the Project Secretary may together stand in for the Leader if there is no Leader.

6.2. Composition

  1. The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members.

  2. When there are fewer than 8 members the Technical Committee may recommend new member(s) to the Project Leader, who may choose (individually) to appoint them or not.

  3. When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6.

  4. When there have been 5 members or fewer for at least one week the Project Leader may appoint new member(s) until the number of members reaches 6, at intervals of at least one week per appointment.

  5. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee.

6.3. Procedure

  1. The Technical Committee uses the Standard Resolution Procedure.

    A draft resolution or amendment may be proposed by any member of the Technical Committee. There is no minimum discussion period; the voting period lasts for up to one week, or until the outcome is no longer in doubt. Members may change their votes. There is a quorum of two.

  2. Details regarding voting

    The Chairman has a casting vote. When the Technical Committee votes whether to override a Developer who also happens to be a member of the Committee, that member may not vote (unless they are the Chairman, in which case they may use only their casting vote).

  3. Public discussion and decision-making.

    Discussion, draft resolutions and amendments, and votes by members of the committee, are made public on the Technical Committee public discussion list. There is no separate secretary for the Committee.

  4. Confidentiality of appointments.

    The Technical Committee may hold confidential discussions via private email or a private mailing list or other means to discuss appointments to the Committee. However, votes on appointments must be public.

  5. No detailed design work.

    The Technical Committee does not engage in design of new proposals and policies. Such design work should be carried out by individuals privately or together and discussed in ordinary technical policy and design forums.

    The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere.

    Individual members of the technical committee may of course participate on their own behalf in any aspect of design and policy work.

  6. Technical Committee makes decisions only as last resort.

    The Technical Committee does not make a technical decision until efforts to resolve it via consensus have been tried and failed, unless it has been asked to make a decision by the person or body who would normally be responsible for it.

7. The Project Secretary

7.1. Powers

The Secretary:

  1. Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution.

  2. Can stand in for the Leader, together with the Chairman of the Technical Committee.

    If there is no Project Leader then the Chairman of the Technical Committee and the Project Secretary may by joint agreement make decisions if they consider it imperative to do so.

  3. Adjudicates any disputes about interpretation of the constitution.

  4. May delegate part or all of their authority to someone else, or withdraw such a delegation at any time.

7.2. Appointment

The Project Secretary is appointed by the Project Leader and the current Project Secretary.

If the Project Leader and the current Project Secretary cannot agree on a new appointment, they must ask the Developers by way of General Resolution to appoint a Secretary.

If there is no Project Secretary or the current Secretary is unavailable and has not delegated authority for a decision then the decision may be made or delegated by the Chairman of the Technical Committee, as Acting Secretary.

The Project Secretary's term of office is 1 year, at which point they or another Secretary must be (re)appointed.

7.3. Procedure

The Project Secretary should make decisions which are fair and reasonable, and preferably consistent with the consensus of the Developers.

When acting together to stand in for an absent Project Leader the Chairman of the Technical Committee and the Project Secretary should make decisions only when absolutely necessary and only when consistent with the consensus of the Developers.

8. The Project Leader's Delegates

8.1. Powers

The Project Leader's Delegates:

  1. have powers delegated to them by the Project Leader;
  2. may make certain decisions which the Leader may not make directly, including approving or expelling Developers or designating people as Developers who do not maintain packages. This is to avoid concentration of power, particularly over membership as a Developer, in the hands of the Project Leader.

8.2. Appointment

The Delegates are appointed by the Project Leader and may be replaced by the Leader at the Leader's discretion. The Project Leader may not make the position as a Delegate conditional on particular decisions by the Delegate, nor may they override a decision made by a Delegate once made.

8.3. Procedure

Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion.

9. Assets held in trust for Debian

In most jurisdictions around the world, the Debian project is not in a position to directly hold funds or other property. Therefore, property has to be owned by any of a number of organisations as detailed in §9.2.

Traditionally, SPI was the sole organisation authorized to hold property and monies for the Debian Project. SPI was created in the U.S. to hold money in trust there.

SPI and Debian are separate organisations who share some goals. Debian is grateful for the legal support framework offered by SPI.

9.1. Relationship with Associated Organizations

  1. Debian Developers do not become agents or employees of organisations holding assets in trust for Debian, or of each other, or of persons in authority in the Debian Project, solely by the virtue of being Debian Developers. A person acting as a Developer does so as an individual, on their own behalf. Such organisations may, of their own accord, establish relationships with individuals who are also Debian developers.

9.2. Authority

  1. An organisation holding assets for Debian has no authority regarding Debian's technical or nontechnical decisions, except that no decision by Debian with respect to any property held by the organisation shall require it to act outside its legal authority.

  2. Debian claims no authority over an organisation that holds assets for Debian other than that over the use of property held in trust for Debian.

9.3. Trusted organisations

Any donations for the Debian Project must be made to any one of a set of organisations designated by the Project leader (or a delegate) to be authorized to handle assets to be used for the Debian Project.

Organisations holding assets in trust for Debian should undertake reasonable obligations for the handling of such assets.

Debian maintains a public List of Trusted Organisations that accept donations and hold assets in trust for Debian (including both tangible property and intellectual property) that includes the commitments those organisations have made as to how those assets will be handled.

A. Standard Resolution Procedure

These rules apply to communal decision-making by committees and plebiscites, where stated above.

A.1. Proposal

The formal procedure begins when a draft resolution is proposed and sponsored, as required.

A.1. Discussion and Amendment

  1. Following the proposal, the resolution may be discussed. Amendments may be made formal by being proposed and sponsored according to the requirements for a new resolution, or directly by the proposer of the original resolution.
  2. A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match.
  3. If a formal amendment is not accepted, or one of the sponsors of the resolution does not agree with the acceptance by the proposer of a formal amendment, the amendment remains as an amendment and will be voted on.
  4. If an amendment accepted by the original proposer is not to the liking of others, they may propose another amendment to reverse the earlier change (again, they must meet the requirements for proposer and sponsor(s).)
  5. The proposer of a resolution may suggest changes to the wordings of amendments; these take effect if the proposer of the amendment agrees and none of the sponsors object. In this case the changed amendments will be voted on instead of the originals.
  6. The proposer of a resolution may make changes to correct minor errors (for example, typographical errors or inconsistencies) or changes which do not alter the meaning, providing noone objects within 24 hours. In this case the minimum discussion period is not restarted.

A.2. Calling for a vote

  1. The proposer or a sponsor of a motion or an amendment may call for a vote, providing that the minimum discussion period (if any) has elapsed.
  2. The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments.
  3. The person who calls for a vote states what they believe the wordings of the resolution and any relevant amendments are, and consequently what form the ballot should take. However, the final decision on the form of ballot(s) is the Secretary's - see 7.1(1), 7.1(3) and A.3(4).
  4. The minimum discussion period is counted from the time the last formal amendment was accepted, or since the whole resolution was proposed if no amendments have been proposed and accepted.

A.3. Voting procedure

  1. Each resolution and its related amendments is voted on in a single ballot that includes an option for the original resolution, each amendment, and the default option (where applicable).
  2. The default option must not have any supermajority requirements. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement.
  3. The votes are counted according to the rules in A.6. The default option is Further Discussion, unless specified otherwise.
  4. In cases of doubt the Project Secretary shall decide on matters of procedure.

A.4. Withdrawing resolutions or unaccepted amendments

The proposer of a resolution or unaccepted amendment may withdraw it. In this case new proposers may come forward keep it alive, in which case the first person to do so becomes the new proposer and any others become sponsors if they aren't sponsors already.

A sponsor of a resolution or amendment (unless it has been accepted) may withdraw.

If the withdrawal of the proposer and/or sponsors means that a resolution has no proposer or not enough sponsors it will not be voted on unless this is rectified before the resolution expires.

A.5. Expiry

If a proposed resolution has not been discussed, amended, voted on or otherwise dealt with for 4 weeks the secretary may issue a statement that the issue is being withdrawn. If none of the sponsors of any of the proposals object within a week, the issue is withdrawn.

The secretary may also include suggestions on how to proceed, if appropriate.

A.6. Vote Counting

  1. Each voter's ballot ranks the options being voted on. Not all options need be ranked. Ranked options are considered preferred to all unranked options. Voters may rank options equally. Unranked options are considered to be ranked equally with one another. Details of how ballots may be filled out will be included in the Call For Votes.
  2. If the ballot has a quorum requirement R any options other than the default option which do not receive at least R votes ranking that option above the default option are dropped from consideration.
  3. Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration.
    1. Given two options A and B, V(A,B) is the number of voters who prefer option A over option B.
    2. An option A defeats the default option D by a majority ratio N, if V(A,D) is strictly greater than N * V(D,A).
    3. If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1.
  4. From the list of undropped options, we generate a list of pairwise defeats.
    1. An option A defeats an option B, if V(A,B) is strictly greater than V(B,A).
  5. From the list of [undropped] pairwise defeats, we generate a set of transitive defeats.
    1. An option A transitively defeats an option C if A defeats C or if there is some other option B where A defeats B AND B transitively defeats C.
  6. We construct the Schwartz set from the set of transitive defeats.
    1. An option A is in the Schwartz set if for all options B, either A transitively defeats B, or B does not transitively defeat A.
  7. If there are defeats between options in the Schwartz set, we drop the weakest such defeats from the list of pairwise defeats, and return to step 5.
    1. A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) is less than V(B,Y). Also, (A,X) is weaker than (B,Y) if V(A,X) is equal to V(B,Y) and V(X,A) is greater than V(Y,B).
    2. A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat.
  8. If there are no defeats within the Schwartz set, then the winner is chosen from the options in the Schwartz set. If there is only one such option, it is the winner. If there are multiple options, the elector with the casting vote chooses which of those options wins.

Note: Options which the voters rank above the default option are options they find acceptable. Options ranked below the default options are options they find unacceptable.

When the Standard Resolution Procedure is to be used, the text which refers to it must specify what is sufficient to have a draft resolution proposed and/or sponsored, what the minimum discussion period is, and what the voting period is. It must also specify any supermajority and/or the quorum (and default option) to be used.

B. Use of language and typography

The present indicative (is, for example) means that the statement is a rule in this constitution. May or can indicates that the person or body has discretion. Should means that it would be considered a good thing if the sentence were obeyed, but it is not binding. Text marked as a citation, such as this, is rationale and does not form part of the constitution. It may be used only to aid interpretation in cases of doubt.

doc-debian-6.1/README.build0000664000000000000000000000207012037615610012213 0ustar - The documents under doc/ can be auto-updated if you have a local website CVS copy. It currently only works for english but could be easily expanded to provide all translations. Do we want to do this or should this be handled by the doc-debian-XX packages ? Note: some of the doc-debian-XX packages are really out of date and don't provide the same content that is available in doc-debian ---------------------------------------------------------------- Javier Fernandez-Sanguino Last updated: Wed, 02 Apr 2008 08:03:00 +0200 Build instructions: root@nagy:~# aptitude update && aptitude -V install wml joostvb@nagy:~/debian% ln -s ../cvs/cvs.debian.org/webwml www joostvb@nagy:~/sv...ackages/trunk/doc-debian% cat ~/bin/svn-prebuild #!/bin/sh test -d $buildArea/doc-debian-3.1.6/doc || mkdir -p $buildArea/doc-debian-3.1.6/doc cp doc/Makefile $buildArea/doc-debian-3.1.6/doc make -C $buildArea/doc-debian-3.1.6/doc svn-buildpackage -uc -us -rfakeroot --svn-ignore --svn-dont-purge --svn-lintian --svn-linda --svn-prebuild=svn-prebuild --svn-reuse doc-debian-6.1/debian/0000775000000000000000000000000012060352037011455 5ustar doc-debian-6.1/debian/rules0000775000000000000000000000214012060350761012534 0ustar #!/usr/bin/make -f # derived from sample debian/rules file for GNU hello by Ian Jackson. # Set this to enable debugging export DH_VERBOSE = 1 include /usr/share/cdbs/1/rules/debhelper.mk build/doc-debian:: cd doc && $(MAKE) clean:: cd doc && $(MAKE) clean get-orig-source:: cd doc && $(MAKE) update #install:: # TODO - move the files # cp $(docdir)/constitution.1.3.txt ../constitution.txt # cp $(docdir)/social-contract.txt ../social-contract.txt binary-indep/doc-debian:: dpkg-distaddfile constitution.txt byhand - dpkg-distaddfile social-contract.txt byhand - # Code disabled: There already is a mechanism (which one?) # synching files over to f.d.o/debian/doc although not exactly the # same (it retains page footers, which this one doesn't) # # cp $(docdir)/debian-manifesto ../ # dpkg-distaddfile debian-manifesto byhand - # ( cd $(docdir) && ls *.txt) | \ # grep -v constitution | \ # grep -v social-contract | \ # while read txtfile; do \ # cp $(docdir)/$$txtfile ../ ; \ # dpkg-distaddfile $$txtfile byhand - ; \ # done doc-debian-6.1/debian/control0000664000000000000000000000220012060350761013054 0ustar Source: doc-debian Section: doc Priority: standard Maintainer: Ubuntu Developers XSBC-Original-Maintainer: Javier Fernandez-Sanguino Pen~a Uploaders: Josip Rodin Standards-Version: 3.9.3 Build-Depends-Indep: debhelper (>= 8.0.0), cdbs, wml, lynx Vcs-Browser: http://svn.debian.org/wsvn/ddp/packages/trunk/doc-debian/ Vcs-Svn: svn://svn.debian.org/ddp/packages/trunk/doc-debian/ Package: doc-debian Architecture: all Suggests: www-browser, postscript-viewer Recommends: debian-faq Description: Debian Project documentation and other documents The Debian Project is an association of individuals who have made common cause to create a free operating system. . In this package, you will find: * Debian Linux Manifesto, * Constitution for the Debian Project, * Debian GNU/Linux Social Contract, * Debian Free Software Guidelines. . Additionally provided are: * Debian Bug Tracking System documentation, and * Introduction to the Debian mailing lists. . All of these files are available at ftp://ftp.debian.org/debian/doc/ and mirrors thereof. doc-debian-6.1/debian/copyright0000664000000000000000000001422711003202402013400 0ustar This is the Debian GNU/Linux `doc-debian' package. It provides various important documentation describing Debian. This package was first put together by Sven Rudolph, and later maintained by Santiago Vila. Current maintainer is Josip Rodin . The copyright and license statement for the BTS (applies to docs): copyright 1999 Darren O. Benham, 1994-7 Ian Jackson, 1997 nCipher Corporation Ltd, 1995 Steven Brenner. Available under the GPL. On Debian systems, the complete text of the GNU General Public License is available in `/usr/share/common-licenses/GPL' file. The copyright and license statement for the documentation available at www.debian.org (applies some of the files under docs) © 1997-2004 Software in the Public Interest, Inc. P.O. Box 502761 Indianapolis, IN 46250-2761 United States Tis material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later: --------------------------------------------------------------------- OPL license v1.0, 8 June 1999 I. REQUIREMENTS ON BOTH UNMODIFIED AND MODIFIED VERSIONS The Open Publication works may be reproduced and distributed in whole or in part, in any medium physical or electronic, provided that the terms of this license are adhered to, and that this license or an incorporation of it by reference (with any options elected by the author(s) and/or publisher) is displayed in the reproduction. Proper form for an incorporation by reference is as follows: Copyright (c) by . This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, vX.Y or later (the latest version is presently available at http://www.opencontent.org/openpub/). The reference must be immediately followed with any options elected by the author(s) and/or publisher of the document (see section VI). Commercial redistribution of Open Publication-licensed material is permitted. Any publication in standard (paper) book form shall require the citation of the original publisher and author. The publisher and author's names shall appear on all outer surfaces of the book. On all outer surfaces of the book the original publisher's name shall be as large as the title of the work and cited as possessive with respect to the title. II. COPYRIGHT The copyright to each Open Publication is owned by its author(s) or designee. III. SCOPE OF LICENSE The following license terms apply to all Open Publication works, unless otherwise explicitly stated in the document. Mere aggregation of Open Publication works or a portion of an Open Publication work with other works or programs on the same media shall not cause this license to apply to those other works. The aggregate work shall contain a notice specifying the inclusion of the Open Publication material and appropriate copyright notice. SEVERABILITY. If any part of this license is found to be unenforceable in any jurisdiction, the remaining portions of the license remain in force. NO WARRANTY. Open Publication works are licensed and provided "as is" without warranty of any kind, express or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose or a warranty of non-infringement. IV. REQUIREMENTS ON MODIFIED WORKS All modified versions of documents covered by this license, including translations, anthologies, compilations and partial documents, must meet the following requirements: * The modified version must be labeled as such. * The person making the modifications must be identified and the modifications dated. * Acknowledgement of the original author and publisher if applicable must be retained according to normal academic citation practices. * The location of the original unmodified document must be identified. * The original author's (or authors') name(s) may not be used to assert or imply endorsement of the resulting document without the original author's (or authors') permission. V. GOOD-PRACTICE RECOMMENDATIONS In addition to the requirements of this license, it is requested from and strongly recommended of redistributors that: * If you are distributing Open Publication works on hardcopy or CD-ROM, you provide email notification to the authors of your intent to redistribute at least thirty days before your manuscript or media freeze, to give the authors time to provide updated documents. This notification should describe modifications, if any, made to the document. * All substantive modifications (including deletions) be either clearly marked up in the document or else described in an attachment to the document. * Finally, while it is not mandatory under this license, it is considered good form to offer a free copy of any hardcopy and CD-ROM expression of an Open Publication-licensed work to its author(s). VI. LICENSE OPTIONS The author(s) and/or publisher of an Open Publication-licensed document may elect certain options by appending language to the reference to or copy of the license. These options are considered part of the license instance and must be included with the license (or its incorporation by reference) in derived works. A. To prohibit distribution of substantively modified versions without the explicit permission of the author(s). "Substantive modification" is defined as a change to the semantic content of the document, and excludes mere changes in format or typographical corrections. To accomplish this, add the phrase `Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.' to the license reference or copy. B. To prohibit any publication of this work or derivative works in whole or in part in standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder. To accomplish this, add the phrase 'Distribution of the work or derivative of the work in any standard (paper) book form is prohibited unless prior permission is obtained from the copyright holder.' to the license reference or copy. --------------------------------------------------------------------- doc-debian-6.1/debian/doc-debian.install0000664000000000000000000000011112037631763015035 0ustar doc/*.txt usr/share/doc/debian doc/debian-manifesto usr/share/doc/debian doc-debian-6.1/debian/doc-debian.doc-base.debian-social-contract0000664000000000000000000000104612037631433021352 0ustar Document: debian-social-contract Title: The Debian Social Contract, and the Debian Free Software Guidelines Author: The Debian Project Abstract: This is the "social contract" (v1.1) we offer to the free software community. The Debian Free Software Guidelines (DFGS) are the set of license conditions to be met for packages to be part of the Debian system. The version 1.1 ratified on April 26, 2004. This version supersedes version 1.0, ratified on April 5, 1997. Section: Debian Format: text Files: /usr/share/doc/debian/social-contract.txt.gz doc-debian-6.1/debian/prerm0000775000000000000000000000040311003202402012507 0ustar #!/bin/sh -e if which install-docs >/dev/null 2>&1; then install-docs -r debian-constitution-text install-docs -r debian-reporting-bugs install-docs -r debian-manifesto install-docs -r debian-mailing-lists install-docs -r debian-social-contract fi doc-debian-6.1/debian/doc-debian.doc-base.debian-manifesto0000664000000000000000000000076612037632504020262 0ustar Document: debian-manifesto Title: The Debian Linux Manifesto Author: Ian A. Murdock Abstract: The Debian Manifesto was released in 1993 by Ian Murdock. The document outlines his view for a brand new Linux distribution which would be developed openly, describes why the world needed this distribution and which problems would the distribution solved. This document is provided in order to document Debian's history. Section: Debian Format: text Files: /usr/share/doc/debian/debian-manifesto.gz doc-debian-6.1/debian/doc-debian.doc-base.debian-reporting-bugs0000664000000000000000000000042612037631337021240 0ustar Document: debian-reporting-bugs Title: How to report a bug in Debian Author: Ian Jackson, Steven Brenner and Darren Benham Abstract: Description on how to properly report a bug in Debian GNU/Linux. Section: Debian Format: text Files: /usr/share/doc/debian/bug-reporting.txt.gz doc-debian-6.1/debian/changelog0000664000000000000000000007420312060352021013326 0ustar doc-debian (6.1ubuntu1) raring; urgency=low * Merge from Debian unstable. (LP: #1086940) Remaining changes: - /doc mailing-lists.txt added - /doc/Makefile edited to build regardless mailing-lists.wml existence -- Alessandro Losavio Fri, 07 Dec 2012 11:24:34 +0000 doc-debian (6.1) unstable; urgency=low * Update the contents to the latest available at the website * Simplify debian/rules using CDBS - Use standard build process. This build now ensures that we provide a md5sums file (Closes: #672319) - Text files are now compressed - Some Lintian bugs now go away * debian/control: Add provided Build-Depends * Include the wml sources in the package to make it easier to build the sources when a copy of the website is not available (Closes: #690791) * debian/control: Updated Standards version, no changes needed. -- Javier Fernández-Sanguino Peña Wed, 17 Oct 2012 23:25:00 +0200 doc-debian (6.0) unstable; urgency=low * Update the contents to the latest available at the website * Remove Pierre Machard as Uploader (Closes: 576557) * doc/source-unpack.txt: Apply patch provided by Colin Watson to improve the document. This patch documents all formats currently in use in the Debian archive. (Closes: #579263) -- Javier Fernández-Sanguino Peña Sat, 14 Apr 2012 12:08:29 +0200 doc-debian (4.0.2ubuntu1) lucid; urgency=low * Merge from debian testing. Remaining changes: LP: #517978 + debian/rules: - Removed extra-files section to allow the upload (binary) to the Ubuntu archive. It was rejected due unidentified files (byhand) in changes. - Update Standards Version -- Bhavani Shankar Tue, 09 Feb 2010 20:59:06 +0530 doc-debian (4.0.2) unstable; urgency=low * Fix FTBFS by removing all Build-Depends-Indep dependencies, including tetex-bin and tetex-extra dependencies as they are not really needed (Closes: #562306) * Update the contents of the doc/ subdir with the latest content of the website. - Include the version 1.3 of the constitution - Updated bug-reporting.txt which nows describes X-Debbugs-CC (Closes: #298991, #367602) - Updated bug-maint-mailcontrol.txt which now describes the 'unarchive' option (Closes: 489517) - Update the constitution version to 1.4 (Closes: #520684, #367787) - Update bug-maint-mailcontrol.txt which now describes the possibility of forwarding to URLs (Closes: #457715) * Fix doc/Makefile so that the social contract file is not overwritten with version 1.0 (Closes: #512251) * Modify doc/Makefile so that the constitution.wml file is changed by introducing a heading style before the table of content, this way the formatting of headings is improved (Closes: #520960) -- Javier Fernandez-Sanguino Pen~a Mon, 11 Jan 2010 21:57:50 +0100 doc-debian (4.0.1ubuntu1) intrepid; urgency=low * Merge from debian unstable, remaining changes: + debian/rules: - Removed extra-files section to allow the upload (binary) to the Ubuntu archive. It was rejected due unidentified files (byhand) in changes. + debian/control: - Added gs-esp as Build-Depends-Indep to fix FTBFS - Modified Maintainer value to match the DebianMaintainerField specification. - Update Standards Version. -- Emanuele Gentili Fri, 18 Jul 2008 05:26:21 +0200 doc-debian (4.0.1) unstable; urgency=low [ Changes by Joost van Baal ] * This package now is maintained using Subversion. - debian/control: Add Vcs-* headers. - TODO: add build instructions. * The Debian GNU/Linux FAQ no longer is shipped with this package, but via the new debian-faq source package. - debian/{control,postinst,prerm,changelog,copyright,rules}, doc-base/debian-faq: remove Debian FAQ stuff. - debian/control: this package now Recommends debian-faq. * debian/control: Bump Standards-Version from 3.6.2.0 to 3.7.3 (no changes needed.) * debian/copyright: convert encoding from ISO-8859 to UTF-8 Unicode. * doc/{source-unpack.txt,debian-manifesto}: now kept in our own SVN (these are not published on the Debian website). -- Javier Fernandez-Sanguino Pen~a Tue, 29 Apr 2008 03:07:23 +0200 doc-debian (4.0) unstable; urgency=low * Update to the latest contents of the FAQ in CVS: - updates list of supported architectures - adjust number of packages/developers/arches - describe use of initrd in make-kpkg - proper description of Debian package names (Closes: #443472) - describe tasksel as well as aptitude in package management - say that aptitude is the preferred tool for *console* management (Closes: #418455) - add a note related to Mozilla rebranding - X Window System -> Xorg - describe how to install a developer's environment - fix location of mirror list - init handles runlevels, not the kernel (Closes: #416203) - 'bug-reporting' now describes nnn-quiet (Closes: #367548) - typo fixes in consitution.txt (Closes: #367787) * Update to the latest contents of the www pages (bugs and constitution) - fix a typo in the constitution (Closes: #367787) -- Javier Fernandez-Sanguino Pen~a Sun, 23 Sep 2007 14:49:22 +0200 doc-debian (3.1.5ubuntu2) hardy; urgency=low * debian/rules: + Removed extra-files section to allow the upload (binary) to the Ubuntu archive. It was rejected due unidentified files (byhand) in changes. (LP: #187726) -- Miguel Ruiz Mon, 11 Feb 2008 13:31:10 -0300 doc-debian (3.1.5ubuntu1) hardy; urgency=low * debian/control: + Added gs-esp as Build-Depends-Indep to fix FTBFS (LP: #187726) + Modified Maintainer value to match the DebianMaintainerField specification. -- Miguel Ruiz Thu, 31 Jan 2008 12:56:52 -0300 doc-debian (3.1.5) unstable; urgency=high [ High urgency, since the previous version was shipping out of date versions of Debian's core documents and still refered to sarge as the latest releas e] * Updated the contents under doc/ with the latest version from the website * Synchronise the FAQ contents with CVS: - Update the numbers - Add 'lenny' into the list of codenames - Update and expand the contents of the standard task (no longer includes developer tools) - AMD64 is already available as an official arquitecture * Added the latest version of the constitution and the social-contract as byhand files so FTP masters can update the contents of ftp-master's doc/ directories (Closes: 262425) -- Javier Fernandez-Sanguino Pen~a Wed, 17 Jan 2007 09:07:56 +0100 doc-debian (3.1.4) unstable; urgency=low [ Changes by Joost van Baal ] * Update software.sgml, as Java is now free (Closes: #398682) [ Changes by Jens Seidel ] * Update kernel.sgml with some markups and pending FIXMes [ Changes by Javier Fernandez-Sanguino ] * Added an item in the TODO * Update the Makefile to clean some files that were not removed from the package and broke multiple rebuilds. -- Javier Fernandez-Sanguino Pen~a Sun, 19 Nov 2006 11:46:53 +0100 doc-debian (3.1.3) unstable; urgency=low [ Changes by Joost van Baal ] * doc/Makefile: get rid of hardcoded /home/jfs, so that it works on joostvb's system too. Add rule to generate mailing-lists.txt from webwml CVS. Generate both social-contract.1.0 and social-contract.1.1. Generate all 3 versions of constitution. * debian/rules: replace obsolete refresh target with referral to new doc/Makefile by jfs. * debian/control: Bump Standards-Version from 3.6.1 to 3.6.2.0 (no changes needed.) * Update the CVS-managed part of the content of the files under doc/ to their latest versions, from cvs.debian.org webwml/webwml/english (as published on http://www.debian.org/) (Closes: #149401) - The bug-mailserver-refcard now documents the 'found' command (Closes: #352175) - The bug-maint-info.txt file now describes sarge as released and etch as unreleased (Closes: #353249) * Update the content of the files under FAQ/ to their latest CVS versions, from cvs.debian.org debian-doc/ddp/manuals.sgml/faq: - changes by jseidel, 2006-01-31, 2005-09-04, 2005-08-11 * kernel.sgml: The manual page of make-kpkg is in section 1 not 8 (compare Bug#350530). Also changed to tag for a file name. * pkg_basics.sgml: The manual page of dpkg-deb is in section 1 not 8 (compare Bug#350523). * basic_defs.sgml, compat.sgml: s/RedHat/Red Hat/ * ftparchives.sgml: fixed full-stops, thanks Luca Brivio - changes by joostvb, 2005-12-08 - 2006-01-01 * uptodate.sgml: Add notes on dpkg --log flag, and on aptitude logging capabilities. (Closes: #342790) * getting.sgml: add note on frozen and unstable symlinks in cdimages. (Closes: #68477) * support.sgml: style consistency: s/email/e-mail/ * pkgtools.sgml: refer to APT HOWTO. (Closes: #343120) * support.sgml: Notes on how to report bugs that affect many package don't belong here, but on http://www.debian.org/Bugs/Reporting : don't copy information from that document. (Closes: #342871) * compat.sgml: Add note on LSB to answer "How compatible is Debian". (Closes: #342823) * getting.sgml: add an extra link to installmanual, next to our own installation instructions * pkgtools.sgml: when talking about automatically purging no-longer needed dependency packages, mention libraries too. See Bug #315861 * redist.sgml: Corel Linux and Storm Linux are (almost) gone; better mention Progeny Debian, Linspire, Knoppix and Ubuntu. Mention CDD when talking about Debian-derived distributions. (I guess the note on "Linux for Hams" should probably either get removed, or get replaced by a link to the newer "Debian-Ham"...) * support.sgml: refer to relevant social contract clause when introducing bts * support.sgml: be clear about the public nature of the Debian mailing lists * support.sgml: when mentioning dwww and dhelp, mention doc-central too * basic_defs.sgml: refer to list of other docs as well as notes on giving feedback in intro * kernel.sgml, support.sgml: get rid of last remnants of pre-/u/s/d transition * customizing.sgml: mention invoke-rc.d * kernel.sgml: grub is now the standard bootloader on i386; generally there is no need to run LILO * uptodate.sgml: add and integrate section on aptitude * basic_defs.sgml: link to relevant other faq entry * software.sgml: typo: s/Sun icrosystems/Sun Microsystems/ * software.sgml: mention changelog too as a place to see who has done what. adjust to /u/s/d transition * software.sgml: mention current popular software like GIMP, PostgreSQL, MySQL, Mozilla, OOo, Gnumeric too * basic_defs.sgml: link to relevant other faq entry * basic_defs.sgml, faqstatic.ent: do not hardcode statistics but use faqstatic.ent. * basic_defs.sgml: More reasons to choose Debian: DFSG, Social Contract, # packages, # architectures. Gentoo exists, Debian is no longer "the only Linux distribution that is being developed cooperatively by many individuals through the Internet". (Closes: #340655) * basic_defs.sgml: hurd isn't "new", mention *BSD-ports too. (Closes: #339756) * basic_defs.sgml: Linux ports to non-i386 architectures are mature. (Closes: #335869) * ftparchives.sgml: Added "How do I set up my own apt-able repository?". (Closes: #333511) * basic_defs.sgml: Add "What is this FAQ?" question, with purposes of FAQ, intended audience, assumed knowledge (Closes: #333504) [ Javier Fernandez-Sanguino ] - hijack this package from Josip as he can no longer take care of this package. - add some more TODO things. - changes to the FAQ, 2005-09-14 - 2005-06-06 * software.sgml: Describe also where is qmail, ezmlm and djbdns as suggested by Seo Sanghyeon * software.sgml: Changed the sections to reflect the fact that non-US is now obsolete as suggested by Seo Sanghyeon * pkgtools.sgml: Added dlocate and apt-file as suggested by Seo Sanghyeon * basic_defs.sgml, compat.sgml, contrib.sgml, customizing.sgml, faqinfo.sgml, ftparchives.sgml, getting.sgml, kernel.sgml, nexttime.sgml, pkg_basics.sgml, pkgtools.sgml, redist.sgml, software.sgml, support.sgml, uptodate.sgml: Added revision tracking for translations * debian-faq.sgml, faqinfo.sgml: Updated year of (c) and added myself as maintainer for the FAQ * pkgtools.sgml, software.sgml: More improvements in the package management tools sections: - order tools by level (increasing) and separate developer's only tools - more information on the tools and an additional cross-reference - another TODO, should describe also using apt 'a la' Gentoo * pkgtools.sgml: Enhancements to the tools section and typo fixes in Eric's patch * pkgtools.sgml: Tools enhancement patch from Eric * getting.sgml, pkgtools.sgml: Fix SGML errors with patches sent by Eric * support.sgml: Removed bug package, no longer available, and add a comment on looking for already reported bugs with reportbug * pkgtools.sgml: Added TODO * ftparchives.sgml: Modified references to frozen as suggested by Santiago Vila * customizing.sgml: Changed libpaperg to libpaper1 as suggested by Santiago Vila * compat.sgml: Removed references to xlib6 (which does not exist any longer) as suggested by Santiago Vila * compat.sgml: Removed obsolete section on a.out programs as suggested by Santiago Vila * TODO: Reorganise listing to have obscure entries last * pkgtools.sgml: Added a section about -data packages (Closes: #315861) * getting.sgml: Added section on package upgrades for stable also added pointers to the Debian Security FAQ and Manual since they are valuable for those interested in the security aspects of Debian (Closes: #310770) * ftparchives.sgml: Forgot to mention woody in the oldcodenames item * faqstatic.ent: Preparation for sarge release -- Javier Fernandez-Sanguino Pen~a Tue, 25 Apr 2006 10:49:22 +0200 doc-debian (3.1.2) unstable; urgency=low * Add OPL license since that's the license of the documents published in the website which are reused in this package (Closes: #207549) * Clean up debian-faq.tpt since it's a binary file generated automatically. * Updated the wml documents with the latest copy from the website -- Javier Fernandez-Sanguino Pen~a Thu, 9 Jun 2005 15:54:20 +0200 doc-debian (3.1.1) unstable; urgency=high * Real update for imminent Sarge release, urgency high since this content needs to be updated to be available in the official CDs and DVDs: - ftparchives.sgml: stable points to sarge instead of woody (Closes: #265587) * Use the wml files from a local www copy instead of the 'refresh' rule to make it easier to keep track of changes in the web pages No Build-Depends changes since the maintainer can simply 'make' the change happen if they have wml and lynx but it is not done automatically when built. Note to maintainers: adjust the WEBWML variable in doc/Makefile before running 'make' (Closes: #303486) * Update the content of the files under doc/ to their latest version from the web site. * Update the content of the files under FAQ/ to their latest CVS versions: - faqstatic.ent: Updated info for sarge release (Closes: #304156) - pkg_basics.sgml: Add information about essential packages (Closes #202495) - pkg_basics.sgml: Fix references to the packaging manual which is no longer available (#306493) - pkg_basics.sgml: Describe how aptitude can be used to hold/unhold packages (Closes: #309777) - nexxtime.sgml: Improvements to the next things for etch, not a full rewrite, but will do (Closes: #304130) - pkgtools.sgml and uptodate.sgml: The apt guide is now provided in apt-doc. (Closes: #304156) - pkgtools.sgml: Better indication of Contents location (Closes: #283033) - support.sgml: Added a reference to the DDP documents and also added a pointer to the Debian Reference (Closes: #276625) - debian-faq.sgml: Reference to the authors section (Closes: #202491) - update.sgml: APT is 'advanced' (Closes: #241094) - pkg_basics.sgml: Remove emacs from standard and add gcc/g++ as well as standard server software also document what gets installed in a standard installation (Closes: #303987) - software.sgml: Complete sentence (Closes: #291790) - software.sgml: Be more verbose about Java support, use patch provided by Jeroen van Wolffelaar (Closes: #299434) * Use which instead of command -v in maintainer scripts (Closes: #292972) * Added myself as uploader -- Javier Fernandez-Sanguino Pen~a Fri, 3 Jun 2005 00:24:50 +0200 doc-debian (3.1) unstable; urgency=high * Update for imminent Sarge release * Refresh the files from the FTP site (closes: #252794, #220291) * Upgrade constitution.txt to 1.2 (closes: #222102) * Add constitution.1.0.txt, constitution.1.1.txt * Upgrade the social-contract to version 1.1 * Add social-contract 1.0 * Fix location of README for kernel-package in FAQ/kernel.sgml (closes: #183020) * Bump Standards-Version to 3.6.1 * Added myself as package uploader -- Pierre Machard Tue, 10 Aug 2004 19:05:21 +0200 doc-debian (3.0.2) unstable; urgency=low * Propagating the updates from CVS to the package. -- Josip Rodin Tue, 28 Jan 2003 15:27:46 +0100 doc-debian (3.0.1) unstable; urgency=low * Propagating the updates from CVS to the package. * Mentioned apt-get build dep, closes: #103108. * Mentioned alien explicitely, closes: #129420. * Thanks to Tollef Fog Heen for a lot of proofreading and URL fixes, Osamu Aoki for an update to the init script system description, Javier F.S.P. for an update to the code names sections. * Normalized titles, added a link to the testing web page. * Refreshed the files from the FTP site. -- Josip Rodin Sat, 31 Aug 2002 15:09:02 +0200 doc-debian (3.0) unstable; urgency=critical * Updated for the imminent woody release. * Updated BTS docs from the FTP site, closes: #133422, #133440. * Updated description of frozen, closes: #142801. * Built a PDF version. -- Josip Rodin Tue, 30 Apr 2002 19:02:09 +0200 doc-debian (2.2.5) unstable; urgency=low * A bunch of fixes in the FAQ, including a rewritten section about Java, which closes: #115807. * Replaced Build-Depends with Build-Depends-Indep. -- Josip Rodin Wed, 31 Oct 2001 23:48:43 +0100 doc-debian (2.2.4) unstable; urgency=low * Updated the BTS docs from the FTP site, closes: #99721, #106495, #109293. * Fixed the FTP site URL(s), closes: #100471. * Replaced mention of tee with script, and dpkg -BORGiE with something less specific, closes: #110391. * Other small fixes in the FAQ. -- Josip Rodin Fri, 7 Sep 2001 19:38:53 +0200 doc-debian (2.2.3) unstable; urgency=medium * Removed info on local packages in dselect, because it works only for obsolete access methods; s/Packages.new/my_Packages/ and s/update-avail/merge-avail/ in the other answer, closes: #77096. Added a reference to sources.list. * Included fixes from Colin Watson and Bill Wohler regarding the pool and the testing distribution, closes: #89320. * Updated the answer about X resources regarding the change in their placement, closes: #84808. * Expanded the `difference' section title and added a link to our why_debian web page, closes: #83549. * Added "Why do I get "ld: cannot find -lfoo" messages when compiling programs?" to the other question about that, closes: #83046. ("why can't I compile stuff?" seemed way too generic) * Removed needless build-dependency on debhelper and upped the standards version to 3.5.2. -- Josip Rodin Fri, 24 Nov 2000 22:43:48 +0100 doc-debian (2.2.2) stable unstable; urgency=low * Quite a few updates to the FAQ regarding potato being stable now. (we don't want packages in released potato saying slink is the current stable distribution, don't we? :) * Refreshed the doc/ directory from the FTP site, to include the dedication (with the translations) and an updated mailing-lists.txt file. * Fixed the section about dselect a bit, closes: #67218. * Added a blurb about apt-get in the section about packaging tools, closes: #69784. -- Josip Rodin Sun, 24 Sep 2000 12:13:00 +0200 doc-debian (2.2.1) frozen unstable; urgency=low * Several small updates to the Debian FAQ, including: + s/German/Italian/ in the manpages-it example, closes: #61108 + Added description on how to put a package on hold, closes: #61109 + Mention pine and pico replacements in pine section, closes: #64541 * Synced doc/* files with what's on the FTP site, to remove \0s from the end of two files, closes: #63842. * Removed the directory (debian-faq.html/) from debian-faq.html.tar.gz, it's not quite useful. -- Josip Rodin Sun, 28 May 2000 14:45:12 +0200 doc-debian (2.2) frozen unstable; urgency=low * New maintainer (thanks, Santiago!). * Big update of the Debian FAQ (also closes: #57980, #59132, #60168). * Polished up package to my likings. Removed dvi version of the FAQ. * Now Suggests: www-browser, postscript-viewer, for obvious reasons. -- Josip Rodin Sun, 19 Mar 2000 00:51:17 +0100 doc-debian (2.1.0) frozen unstable; urgency=low * Create a compatibility symlink for /usr/doc/debian also (Bug #57861). * Fixed debian-constitution-text's "Document:" field (Bug #57861). * Moved doc-base location from "Help" to "Debian" (Bug #57980). * Remove all references to the old debian-faq mailing list (Bug #59136). Use doc-debian@packages.debian.org or the bug system instead. * Remove way outdated "list" of Debian mailing lists. Refer to the text version at /usr/share/doc/debian/mailing-lists.txt for now (Bug #59136). -- Santiago Vila Thu, 2 Mar 2000 16:57:39 +0100 doc-debian (2.1) frozen unstable; urgency=low * Removed outdated information about the kernel-source packages (Bug #33469). * Removed outdated information about creating boot floppies (Bug #41771). * Added doc-base support (replacing dwww support). Thanks to Josip Rodin. * Updated figures: 3900 packages. 500 developers. * Minor updates here and there. * Standards-Version: 3.1.1. -- Santiago Vila Sat, 5 Feb 2000 18:49:15 +0100 doc-debian (2.0.1) unstable; urgency=low * Refreshed doc directory from ftp.debian.org. * Updated figures about disk space for mirroring. -- Santiago Vila Fri, 12 Nov 1999 13:14:50 +0100 doc-debian (2.0.0) unstable; urgency=low * Updated information about make-kpkg (Bug #38106). * Fixed minor counting issue in second chapter (Bug #39003). -- Santiago Vila Wed, 7 Jul 1999 16:42:52 +0200 doc-debian (2.0) unstable; urgency=medium * Some updates for slink. * Added a paragraph about pine. * Changed the way debian/add-files manages the index.html file. -- Santiago Vila Wed, 14 Apr 1999 17:52:02 +0200 doc-debian (1.9.3) frozen unstable; urgency=medium * Changed info to become a developer (Bug #30964). Now it simply refers to the developers-reference. * Refer to the appropriate web page for the list of CD-vendors. * Discourage the use of the cdrom dselect access method. * Mention the http://cdimage.debian.org/ site. * Refreshed doc directory from ftp.debian.org. * Fixed and enhanced a lot of minor things. -- Santiago Vila Mon, 25 Jan 1999 20:00:47 +0100 doc-debian (1.9.2) frozen unstable; urgency=medium * Changed contact info for SPI. * Changed reference to lintian home page. * Changed answer to the question about "Can't find libX11.so.6". -- Santiago Vila Sat, 12 Dec 1998 17:48:22 +0100 doc-debian (1.9.1) unstable; urgency=low * Refreshed doc directory from ftp.debian.org. * Switched from sdc to sgml-tools. Otherwise this package would have to be moved to contrib. * Removed the info version of the FAQ for now, since sgml2info is apparently unable to process it. * Added the .dvi version. -- Santiago Vila Tue, 13 Oct 1998 20:28:49 +0200 doc-debian (1.9) unstable; urgency=low * Removed debian-keyring.tar.gz, since it is now in a separate package. * Added "set -e" to prerm, postrm and postinst. Fixes Bug #23975. * Refreshed doc directory from ftp.debian.org. * Minor fixes here and there, for example, the stable release is now for both i386 and m68k. * Rewritten the part about the Debian FTP archives. It has now a separate section. -- Santiago Vila Wed, 12 Aug 1998 18:33:58 +0200 doc-debian (1.8) frozen unstable; urgency=medium * Standarized name for the Intel architecture: 80386 -> 386. * Rewritten the paragraphs about "Major Package Trees". * New questions and answers about libc5 compatibility. * Updated minimal disk space requirements. -- Santiago Vila Tue, 14 Apr 1998 19:32:14 +0200 doc-debian (1.7) unstable; urgency=medium * Removed gnuplot from the list of "major GNU applications". * Updated the "How-to-upgrade" part, by referring to autoup.sh, the libc5-libc6 mini-HOWTO, APT, pkg-order, etc. Still unfinished. * Added a menu entry for dwww. * Updated URL for Linux-PAM. * Fixed some sunsite dangling hyperlinks. * Added a question about "installing" source packages. * Added a question about building binary packages from source packages. * There are only two versions of Debian: 2.0 and the unstable version. (Will be true by the time hamm was released :-). * Version 2.0.32 of the kernel is used in all the examples. -- Santiago Vila Thu, 9 Apr 1998 14:31:56 +0200 doc-debian (1.6) unstable; urgency=medium * Refreshed doc directory from ftp.debian.org. Now a text version of the Social Contract is included. * Added a (previously commented out) paragraph about the GNUish meaning of "free" with a reference to the DFSG. * Updated figures: 1500 packages. 300 developers. * Added a small paragraph about lintian in bugs.sgml (recommend this over submitting several bugs). * Removed grep and gzip from the list of needed packages to compile the kernel, since they are essential. * man-db is now the package providing the man program. * Updated FSF's postal address in the GPL. * init now executes /etc/init.d/rcS, not /etc/init.d/boot. * Added Pentium II to the list of supported hardware in hardware.sgml. * binary symlink is being deprecated. * We do not adhere so "strictly" to the FSSTND since we are moving to the FHS. * Commented out Unifix URL, and changed "is available" by "was available". * Installation instructions for the current release link points now to dists/stable/main/etc. so that it is always current. * debian-policy is now included in its own package. -- Santiago Vila Wed, 8 Apr 1998 14:40:46 +0200 doc-debian (1.5.1) unstable; urgency=low * Refreshed doc directory from ftp.debian.org. In particular, the docs about the bug system have been updated. * Some fixes by James Treacy (dangling hyperlinks etc.). * Changed most gnu.org domain addresses. * New maintainer. -- Santiago Vila Sat, 24 Jan 1998 19:10:21 +0100 doc-debian (1.5.0) unstable; urgency=low * Made self-consistent: local Debian mirror not required anymore. * Installed /usr/doc//changelog.gz * Removed FAQ/tweaked/* from the source. * Cleaned up debian/rules. * Non-maintainer release. -- Santiago Vila Fri, 28 Nov 1997 11:20:32 +0100 doc-debian (1.5-0) frozen unstable; urgency=low * changed Priority: to standard * removed core file (Bug#6393, Bug#7167) * removed package-developer directory (now in debian-policy package) * FAQ updated (fixes #7521) -- Sven Rudolph Thu, 1 May 1997 23:06:01 +0200 doc-debian (1.4-0) stable unstable; urgency=low * updated FAQ (for Debian 1.2) -- Sven Rudolph Sat, 28 Dec 1996 00:06:25 +0100 doc-debian (1.3-0) unstable; urgency=low * deleted 00-INDEX (Bug#5327) * deleted dangling debian-faq.txt symlink (Bug#5181) * updated FAQ * reintroduced html, ascii, ps versions (Bug#5513) -- Sven Rudolph Mon, 18 Nov 1996 22:54:14 +0100 doc-debian (1.2-0) unstable; urgency=low * updated FAQ * deleted .mirror (Bug#4786) -- Sven Rudolph Wed, 23 Oct 1996 21:11:19 +0200 doc-debian (1.1-0) unstable; urgency=low * converted to new source package format * included FAQ source * updated FAQ -- Sven Rudolph Thu, 26 Sep 1996 22:09:30 +0200 Mon Aug 26 21:05:52 1996 Sven Rudolph * FAQ and other files updated Fri Jun 14 02:19:07 1996 Sven Rudolph * releasing 1.0-3 * FAQ updated Thu Mar 14 xx:xx:xx 1996 Sven Rudolph * gzipping all files * debian.control: added Architecture field * debian.control: formatted Description Wed Feb 21 22:53:06 1996 Sven Rudolph * added Debian GNU/Linux package maintenance system files doc-debian-6.1/debian/doc-debian.doc-base.debian-constitution-text0000664000000000000000000000076512037631325022020 0ustar Document: debian-constitution-text Title: Debian Constitution Author: The Debian Project Abstract: This document contains the complete text of Debian Project Constitution (v1.3), in text format. Version 1.3 ratified on September 24th, 2006. Supersedes version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 ratified on December 2nd, 1998 Section: Debian Format: text Files: /usr/share/doc/debian/constitution.txt.gz doc-debian-6.1/debian/doc-debian.doc-base.debian-mailing-lists0000664000000000000000000000035612037631150021040 0ustar Document: debian-mailing-lists Title: Debian mailing lists Author: Debian Listmasters Abstract: A comprehensive list of all mailing lists at lists.debian.org Section: Debian Format: text Files: /usr/share/doc/debian/mailing-lists.txt.gz doc-debian-6.1/debian/postinst0000775000000000000000000000054711003202402013256 0ustar #!/bin/sh -e if which install-docs >/dev/null 2>&1; then install-docs -i /usr/share/doc-base/debian-constitution-text install-docs -i /usr/share/doc-base/debian-reporting-bugs install-docs -i /usr/share/doc-base/debian-manifesto install-docs -i /usr/share/doc-base/debian-mailing-lists install-docs -i /usr/share/doc-base/debian-social-contract fi