else:
row = cursor.fetchone()
- if row[1] != size or row[2] != md5sum:
+ if row[1] != int(size) or row[2] != md5sum:
res = -2
else:
- self.caches[cachename].SetValue(values, row[0])
+ self.caches['files'].SetValue(values, row[0])
res = row[0]
return res
TODO
====
+Various
+-------
+* Implement autosigning, see ftpmaster_autosigning on ftp-master host in text/.
+
* Check TODO.old and move still-valid/useful entries over here.
+* need a testsuite _badly_
* database table "binaries" contains a column 'type TEXT NOT
- NULL'. This should be made a FK on override_type, as it only contains
- deb/udeb strings.
+ NULL'. This should be made a FK on override_type, as it only contains
+ deb/udeb strings.
-- sql query to do the db work for it:
- ALTER TABLE binaries ADD COLUMN new_type INT4 REFERENCES override_type(id);
- UPDATE BINARIES SET new_type = 7 WHERE type = 'deb';
- UPDATE BINARIES SET new_type = 8 WHERE type = 'udeb';
- ALTER TABLE binaries DROP COLUMN type;
- ALTER TABLE binaries RENAME COLUMN new_type TO type;
+ - sql query to do the db work for it:
+ ALTER TABLE binaries ADD COLUMN new_type INT4 REFERENCES override_type(id);
+ UPDATE BINARIES SET new_type = 7 WHERE type = 'deb';
+ UPDATE BINARIES SET new_type = 8 WHERE type = 'udeb';
+ ALTER TABLE binaries DROP COLUMN type;
+ ALTER TABLE binaries RENAME COLUMN new_type TO type;
-- needs updateX.py written and then the rest of the code changed to deal
- with it.
+ - needs updateX.py written and then the rest of the code changed to deal
+ with it.
* Checkout SQL Alchemy and probably use that for our database layer.
+* reject on > or < in a version constraint
+
+* use pythonX.Y-tarfile to check orig.tar.gz timestamps too.
+
+* the .dak stuff is fundamentally braindamaged for various reasons, it
+ should DIE. If we want to cache information - use a ("temporary")
+ database table and let p-a clean it up, e.g. like contents does.
+
+* security global mail overrides should special case buildd stuff so
+ that buildds get ACCEPTED mails. Or maybe send them at
+ new-security-install time. That way upload-security doesn't grow
+ boundlessly.
+
+* debianqueued sucks. Reimplement in a sane way.
+
+NEW processing
+--------------
+* 'dak process-new' allows you to edit the section and change the
+ component, but really shouldn't allow the component change.
+
+* 'dak process-new' doesn't do the right thing with -2 and -1 uploads,
+ as you can end up with the .orig.tar.gz not in the pool or belonging
+ to a wrong suite.
+
+* 'dak process-new' doesn't trap signals from 'dak examine-package' properly
+
+* 'dak queue-report' should footnote the actual notes, and also * the
+ versions with notes so we can see new versions since being noted...
+
+* <neuro> the orig was in NEW, the changes that caused it to be NEW
+ were pulled out in -2, and we end up with no orig in the archive :(
+
+
+
+Override handling
+-----------------
+* 'dak check-overrides' should remove the src-only override when a
+ binary+source override exists
+
+* override checks sucks; it needs to track changes made by the
+ maintainer and pass them onto ftpmaster instead of warning the maintainer.
+
+* Fix component handling in overrides
+
+
+Cruft
+-----
+* 'dak cruft-report' could do with overrides
+
+* cruft-report could spot "half-dropped" binaries. Like if a package
+ used to build A and B, but B is no longer built for half the
+ architectures.
+
+* cruft-report's NVIU check doesn't catch cases where source package
+ changed name, should check binaries too. [debian-devel@l.d.o,
+ 2004-02-03]
+
+* 'dak cruft-report' doesn't look at debian-installer but should.
+
Others
------
- o 'dak check-overrides' should remove the src-only override when a
- binary+source override exists
-
- o reject on > or < in a version constraint
-
o 'dak reject-proposed-updates' should only start an editor once to
capture a message; it will usually be the same message for all
files on the same command line.
-23:07 < aba> elmo: and, how about enhancing 'dak cruft-report' to spot half-dropped
- binaries on one arch (i.e. package used to build A and B, but B is
- no longer built on some archs)?
-
- o tabnanny the source
-
o drop map-unreleased
o check email only portions of addresses match too, iff the names
o 'dak ls' could do better sanity checking for -g/-G (e.g. not more
than one suite, etc.)
- o use python2.2-tarfile (once it's in stable?) to check orig.tar.gz
- timestamps too.
-
o need to decide on whether we're tying for most errors at once.. if
so (probably) then make sure code doesn't assume variables exist and
either way do something about checking error code of check_dsc and
later functions so we skip later checks if they're bailing.
- o the .dak stuff is fundamentally braindamaged, it's not versioned
- so there's no way to change the format, yay me. need to fix.
- probably by putting a version var as the first thing and checking
- that.. auto-upgrade at least from original format would be good.
- might also be a good idea to put everything in one big dict after
- that?
-
o [?, wishlist, distant future] RFC2047-ing should be extended to
all headers of mails sent out.
deal, upload can be retried once the source is in the archive, but
still.
- o security global mail overrides should special case buildd stuff so
- that buildds get ACCEPTED mails (or maybe 'dak security-install' (?)), that way
- upload-security doesn't grow boundlessly.
-
o 'dak security-install' should upload sourceful packages first,
otherwise with big packages (e.g. X) and esp. when source is !i386,
half the arches can be uploaded without source, get copied into
queue/unaccepted and promptly rejected.
- o 'dak cruft-report's NVIU check doesn't catch cases where source
- package changed name, should check binaries
- too. [debian-devel@l.d.o, 2004-02-03]
-
o cnf[Rm::logfile] is misnamed...
<aj> i'd be kinda inclined to go with insisting the .changes file take
BEGIN PGP SIG -- END PGP MESSAGE -- with no lines before or after,
and rejecting .changes that didn't match that
- o 'dak cruft-report' should check for source packages not building any binaries
-
o 'dak control-suite' should have a diff mode that accepts diff output!
o 'dak clean-proposed-updates' doesn't deal with 'dak rm'-d
o 'dak rm' should remove obsolete changes when removing from p-u, or
at least warn. or 'dak reject-proposed-updates' should handle it.
- o need a testsuite _badly_
-
o 'dak process-unchecked' crashes if run as a user in -n mode when
orig.tar.gz is in queue/new...
o check_dsc_against_db's "delete an entry from files while you're
not looking" habit is Evil and Bad.
- o 'dak process-new' allows you to edit the section and change the
- component, but really shouldn't.
-
o 'dak rm' needs to, when not sending bug close mails, promote Cc: to
To: and send the mail anyways.
o UrgencyLog stuff should minimize it's bombing out(?)
o Log stuff should open the log file
- o 'dak queue-report' should footnote the actual notes, and also *
- the versions with notes so we can see new versions since being
- noted...
-
- o 'dak queue-report' should have alternative sorting options, including reverse
- and without or without differentiaion.
-
o 'dak import-users-from-passwd' should sync debadmin and ftpmaster (?)
o <drow> Can't read file.:
You assume that the filenames are relative to accepted/, might want
to doc or fix that.
- o <neuro> the orig was in NEW, the changes that caused it to be NEW
- were pulled out in -2, and we end up with no orig in the archive
- :(
-
o SecurityQueueBuild doesn't handle the case of foo_3.3woody1 with a
new .orig.tar.gz followed by a foo_3.3potato1 with the same
.orig.tar.gz; 'dak process-unchecked' sees it and copes, but the AA
o permissions (paranoia, group write, etc.) configurability and overhaul
- o remember duplicate copyrights in 'dak process-new' and skip them, per package
-
- o <M>ove option for 'dak process-new' byhand proecessing
-
- o 'dak cruft-report' could do with overrides
-
o database.get_location_id should handle the lack of archive_id properly
o the whole versioncmp thing should be documented
- o 'dak process-new' doesn't do the right thing with -2 and -1 uploads, as you can
- end up with the .orig.tar.gz not in the pool
-
- o 'dak process-new' exits if you check twice (aj)
-
- o 'dak process-new' doesn't trap signals from 'dak examine-package' properly
-
- o queued and/or perl on sparc stable sucks - reimplement it.
-
o aj's bin nmu changes
o 'dak process-new':
who their source is; source-must-exist does, but the info is not
propogated down.
- o Fix BTS vs. dak sync issues by queueing(via BSMTP) BTS mail so
- that it can be released on deman (e.g. ETRN to exim).
-
o maintainers file needs overrides
[ change override.maintainer to override.maintainer-from +
o [Hard] Need to merge non-non-US and non-US DBs.
- o experimental needs to auto clean (relative to unstable) [partial:
- 'dak cruft-report' warns about this]
-
o Do a checkpc(1)-a-like which sanitizes a config files.
o fix parse_changes()/build_file_list() to sanity check filenames
o saftey check and/or rename debs so they match what they should be
o s/distribution/suite/g
- o cron.weekly:
- @ weekly postins to d-c (?)
- @ backup of report (?)
- @ backup of changes.tgz (?)
-
o --help doesn't work without /etc/dak/dak.conf (or similar) at
least existing.
o interrupting of stracing 'dak process-unchecked' causes exceptions errors from apt_inst calls
o dependency checking (esp. stable) (partially done)
- o override checks sucks; it needs to track changes made by the
- maintainer and pass them onto ftpmaster instead of warning the
- maintainer.
o need to do proper rfc822 escaping of from lines (as opposed to s/\.//g)
o Revisit linking of binary->source in install() in dak.
- o Fix component handling in overrides (aj)
- o Fix lack of entires in source overrides (aj)
- o direport misreports things as section 'devel' (? we don't use direport)
- o vrfy check of every Maintainer+Changed-By address; valid for 3 months.
o binary-all should be done on a per-source, per-architecture package
basis to avoid, e.g. the perl-modules problem.
o a source-missing-diff check: if the version has a - in it, and it
o dak should validate multi-suite uploads; only possible valid one
is "stable unstable"
o cron.daily* should change umask (aj sucks)
- o 'dak cruft-report' doesn't look at debian-installer but should.
- o 'dak cruft-report' needs to check for binary-less source packages.
- o 'dak cruft-report' could accept a suite argument (?)
o byhand stuff should send notification
- o 'dak poolize' should udpate db; move files, not the other way around [neuro]
o 'dak rm' should update the stable changelog [joey]
o update tagdb.dia
o drop rather dubious currval stuff (?)
o rationalize os.path.join() usage
- o 'dak cruft-report' also doesn't seem to warn about missing binary packages (??)
o logging: hostname + pid ?
o ANAIS should be done in dak (?)
o Add an 'add' ability to 'dak rm' (? separate prog maybe)
- o Replicate old dinstall report stuff (? needed ?)
o Handle the case of 1:1.1 which would overwrite 1.1 (?)
o maybe drop -r/--regex in 'dak ls', make it the default and
implement -e/--exact (a la joey's "elmo")
#!/bin/bash
#
-# $Id: ddtp_i18n_check.sh 1186 2008-08-12 18:31:25Z faw $
+# $Id: ddtp_i18n_check.sh 1670 2009-03-31 20:57:49Z nekral-guest $
#
# Copyright (C) 2008, Felipe Augusto van de Wiel <faw@funlabs.org>
-# Copyright (C) 2008, Nicolas François <nicolas.francois@centraliens.net>
+# Copyright (C) 2008, 2009 Nicolas François <nicolas.francois@centraliens.net>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# Otherwise, list all the errors.
DEBUG=0
+# When DRY_RUN=0, generate the compressed version of the Translation-*
+# files.
+DRY_RUN=0
+
+dists_parent_dir=""
+# If no argument indicates the PACKAGES_LISTS_DIR then use '.'
+PACKAGES_LISTS_DIR=""
+
+usage () {
+ echo "Usage: $0 [options] <dists_parent_dir> [<packages_lists_directory>]" >&2
+ echo "" >&2
+ echo " --debug Debug mode: do not stop after the first error" >&2
+ echo " --dry-run Do not generate the compressed version of the " >&2
+ echo " Translation files">&2
+ exit 1
+}
+
+# Parse options
+for opt; do
+ case "$opt" in
+ "--debug")
+ DEBUG=1
+ ;;
+ "--dry-run")
+ DRY_RUN=1
+ ;;
+ "-*")
+ usage
+ ;;
+ "")
+ echo "Empty parameter" >&2
+ echo "" >&2
+ usage
+ ;;
+ *)
+ if [ -z "$dists_parent_dir" ]; then
+ # Removing trailing /
+ dists_parent_dir=${opt%/}
+ elif [ -z "$PACKAGES_LISTS_DIR" ]; then
+ PACKAGES_LISTS_DIR=$opt
+ else
+ echo "$0: Invalid option: $opt" >&2
+ usage
+ fi
+ ;;
+ esac
+done
+PACKAGES_LISTS_DIR=${opt:-.}
+
+if [ ! -d "$dists_parent_dir" ]; then
+ echo "missing dists_parent_dir, or not a directory" >&2
+ echo "" >&2
+ usage
+elif [ ! -d "$PACKAGES_LISTS_DIR" ]; then
+ echo "missing packages_lists_directory, or not a directory" >&2
+ echo "" >&2
+ usage
+fi
+
#STABLE="lenny"
TESTING="squeeze"
UNSTABLE="sid"
# These special files must exist on the top of dists_parent_dir
SPECIAL_FILES="$SHA256SUMS $TIMESTAMP $TIMESTAMP.gpg"
-usage () {
- echo "Usage: $0 <dists_parent_dir> [<packages_lists_directory>]" >&2
- exit 1
-}
-
-if [ "$#" -lt 1 ] || [ "$#" -gt 2 ] || [ ! -d $1 ]
-then
- usage
-fi
-
# Temporary working directory. We need a full path to reduce the
# complexity of checking SHA256SUMS and cleaning/removing TMPDIR
TEMP_WORK_DIR=$(mktemp -d -t ddtp_dinstall_tmpdir.XXXXXX)
cd "$OLDPWD"
unset TEMP_WORK_DIR
-# If it's traped, something bad happened.
+# If it's trapped, something bad happened.
trap_exit () {
rm -rf "$TMP_WORK_DIR"
- rm -f "$dists_parent_dir"/dists/*/main/i18n/Translation-*.{bz2,gz}
+ rm -f "$dists_parent_dir"/dists/*/main/i18n/Translation-*.bz2
exit 1
}
trap trap_exit EXIT HUP INT QUIT TERM
-# If no argument indicates the PACKAGES_LISTS_DIR then use '.'
-PACKAGES_LISTS_DIR=${2:-.}
-
-if [ ! -d "$PACKAGES_LISTS_DIR" ]
-then
- usage
-fi
-
-# Removing trailing /
-dists_parent_dir=${1%/}
-
is_filename_okay () {
ifo_file="$1"
# We do not check if the md5 in Translation-$lang are
# correct.
- # Now generate files
- # Compress the file
- bzip2 -c "$f" > "$f.bz2"
- gzip -c "$f" > "$f.gz"
+ if [ "$DRY_RUN" = "0" ]; then
+ # Now generate the compressed files
+ bzip2 "$f"
+ fi
else
echo "Neither a file or directory: $f" >&2
exit 1
# Author: Filippo Giunchedi <filippo@debian.org>
# Version: 0.4
+import cgi
import os
import os.path
import cPickle
return False
description = "<pre>Description: %s\nChanges: %s\n</pre>" % \
- (utf2ascii(msg['Description']), utf2ascii(msg['Changes']))
+ (utf2ascii(cgi.escape(msg['Description'])), utf2ascii(cgi.escape(msg['Changes'])))
+
+ link = "http://ftp-master.debian.org/new/%s_%s.html" % \
+ (msg['Source'], msg['Version'])
feed.items.insert(0,
PyRSS2Gen.RSSItem(
title,
pubDate = pubdate,
description = description,
- author = utf2ascii(msg['Maintainer']),
- link = "http://ftp-master.debian.org/new/%s_%s.html" % \
- (msg['Source'], msg['Version'])
+ author = utf2ascii(cgi.escape(msg['Maintainer'])),
+ link = link,
+ guid = link
)
)
-
-<h1>Really crappy page documenting archive criteria</h1>
-
-<h2>Architectures</h2>
-
-<p><b>Release candidates:</b> alpha, amd64, hppa, i386, ia64, mips, mipsel, powerpc
-<br><b>Release hopefuls:</b> arm, s390, sparc
-
-<p><b>Requalification expected:</b> m68k
-<br><b>Future linux ports:</b> armeb
-<br><b>New OS hopefuls:</b> <a href="http://wiki.debian.org/ArchiveQualification/kfreebsd-i386">kfreebsd-i386</a>, win32-i386
-
-<h2>Requirements for architectures</h2>
-
-<p>Examples: amd64, arm, armeb, m68k, s390, sparc
-
-<ul>
-<li>Is port cursed?
-<li>Are machines available to general public?
-<li>Is full source available?
-<li>Is this architecture related to other architectures already in the archive,
-or that also should be considered, either now or in the future? Can the related
-architectures be supported in a single architecture (eg, with a biarch arrangement)?
-<li>Are there 3 or more developers (or n-ms) actively maintaining the port? Who are they?
-<li>What sort of architecture is this? Desktop/workstation? Mainframe/supercomputer? Embedded? Something else?
-<li>Does it have any users? If a desktop system, are there Debian admins who
-run Debian systems on the arch? If an embedded system are there real systems
-shipping that a Debian port will be useful for? If a mainframe system are there
-real systems with many users that a Debian port will be useful for? Who are they?
-<li>Is there kernel and toolchain support? At what level? Are the latest versions supported, or are
-legacy releases required for compatability with some hardware?
-<li>Has the ABI stabalised, or are there major ABI changes coming
-up? Is the ABI stable enough to ensure users will be able just "apt-get
-dist-upgrade" from one version to the next?
-<li>How do you install a system? (URL to a HOWTO)
-<li>Has a buildd been setup? How much of the archive has been built (count by
-source package, builds of old versions are fine for this case)?
-<li>What hardware is potentially available as a fast buildd?
-<li>Is there any corporate support of this arch, and the Debian port in particular?
-<li>Is there an example box developers can login to to see if it works?
-</ul>
-
-<p>It's also worth considering whether the port has any special
-requirements. If the port is mainly for embedded systems, it may be
-appropriate to have different installation or release arrangements
-compared to normal desktop/workstation architectures.
-
-<h2>Further requirements for OSes</h2>
-
-<p>Examples: hurd, opensolaris, kfreebsd
-
-<ul>
-<li>Are there existing comprehensive free distributions of this OS? If
-so, why is a Debian distribution useful?
-<li>What demonstrable benefits does this OS have over existing Debian OSes?
-<li>Does this system have a standard Unix API?
-<li>Does the OS support modern glibc and gcc?
-<li>What is the license on the kernel and libraries? Is it free? Is it GPL
-compatible? (Note that if it's not free, building software for it violates the
-Social Contract; and if it's not GPL compatible, GPL software such as dpkg can't be
-linked to it)
-<li>Does the OS build largely without source changes? If so, what proportion of
-the archive has built?
-</ul>
-
-<p>It's worth thinking about whether it makes sense to integrate the
-port with Debian's Linux-based distribution -- having separate sources
-may not only reduce the impact on the release architectures, but also
-make it easier to do development on the new OS as well.
-
-<p>Note that if significant changes are needed to more than just a small
-number of packages, your porting team will not only need to provide
-patches for most of those changes and make sure they work, but also
-ensure they don't cause problems for existing ports.
-
-
-
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
+ <head>
+ <meta http-equiv="content-type" content="text/xhtml+xml; charset=utf-8" />
+ <link type="text/css" rel="stylesheet" href="style.css" />
+ <link rel="shortcut icon" href="http://www.debian.org/favicon.ico" />
+ <title>
+ Debian Archive criteria
+ </title>
+ </head>
+ <body id="ARCHIVE">
+
+ <div id="logo">
+ <a href="http://www.debian.org/">
+ <img src="http://www.debian.org/logos/openlogo-nd-50.png"
+ alt="debian logo" /></a>
+ <a href="http://www.debian.org/">
+ <img src="http://www.debian.org/Pics/debian.png"
+ alt="Debian Project" /></a>
+ </div>
+ <div id="titleblock">
+
+ <img src="http://www.debian.org/Pics/red-upperleft.png"
+ id="red-upperleft" alt="corner image"/>
+
+ <img src="http://www.debian.org/Pics/red-lowerleft.png"
+ id="red-lowerleft" alt="corner image"/>
+ <img src="http://www.debian.org/Pics/red-upperright.png"
+ id="red-upperright" alt="corner image"/>
+ <img src="http://www.debian.org/Pics/red-lowerright.png"
+ id="red-lowerright" alt="corner image"/>
+ <span class="title">
+ Debian Archive criteria
+ </span>
+ </div>
+
+ <h2>Definitions</h2>
+ <table class="DEFINITION">
+ <thead>
+ <tr>
+ <th> </th>
+ <th>Example</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr class="odd">
+ <td>Architecture</td>
+ <td>amd64, armel, alpha, m68k. Basically everything that uses
+ the Linux kernel.</td>
+ </tr>
+ <tr class="even">
+ <td>OS</td>
+ <td>hurd, opensolaris, kfreebsd. Ports that do not use the
+ Linux kernel, but their own.</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <p>
+ A new architecture has to follow the <em>Rules for new architectures</em>,
+ and answer all <em>Questions for new architectures</em>.
+ </p>
+ <p>
+ A new OS has to follow the <em>Rules for new architectures</em> and
+ answer all <em>Questions for new architectures</em> as well as all
+ <em>Further questions for OSes</em>.
+ </p>
+
+ <p>To have the answers all at one location, please create a page below
+ <a href="http://wiki.debian.org/ArchiveQualification/">wiki.debian.org/ArchiveQualification/</a>.
+ </p>
+
+ <h1>Rules for existing architectures</h1>
+
+ <ul>
+ <li>If an architecture fails to be included in 2 successive
+ official releases, it is moved out of the official archive (and
+ away from the ftp-master.debian.org host).</li>
+
+ <li>If a removed architecture later can prove it will be able to
+ make the next official release, it can be re-included into the
+ official archive. This step additionally needs the acceptance of
+ the Security, the Release and the Debian Admin Team. (It needs
+ security autobuilders, porter machines, etc.)</li>
+ </ul>
+
+ <h1>Rules for new architectures</h1>
+ <ul>
+ <li>A newly included architecture has to be completely built using
+ packages available in plain Debian sources. External patches cannot
+ be used.</li>
+
+ <li>At the time of inclusion a minimal set of binary packages will be
+ imported into the archive, just enough to get build-essential ready to
+ go and an official buildd setup and running. Everything else will be
+ rebuilt from scratch. As soon as enough is rebuilt to get the initial
+ toolchain built using "native" Debian, this will be rebuilt too.</li>
+
+ <li>The packages imported from external source and used for the initial
+ build run must be signed by one of the lead porters, who must be a DD.</li>
+
+ <li>There must be at least two machines ready to be maintained
+ by the Debian System Administrators, so at the start of its
+ lifetime there will be at least one buildd and one porter machine.<br />
+
+ The inclusion into the archive will almost certainly happen before
+ the machines are handed over to DSA, but this should happen as
+ soon as feasible afterwards.
+
+ (Note that this is the minimum to get into the archive. The release team
+ may have additional requirements to allow the architecture to release, so
+ there would normally need to be more machines, especially more
+ buildds.)<br />
+
+ <b>Note:</b> The machines, their setup and hosting etc should be
+ coordinated with DSA and needs to be acceptable to DSA. Please
+ <a href="mailto:debian-admin@lists.debian.org">coordinate with
+ them</a>, they might be able to help you in more ways
+ you can imagine, but at least they can help to avoid useless work
+ if a hosting wouldnt be acceptable. :)
+ </li>
+ </ul>
+
+ <h1>Questions for new architectures</h1>
+ <ul>
+ <!-- <li>Is port cursed?</li> -->
+ <li>Are machines available to buy for the general public?</li>
+ <li>Is full source available?</li>
+ <li>Is this architecture related to other architectures already in
+ the archive, or that also should be considered, either now or in
+ the future? Can the related architectures be supported in a single
+ architecture (eg, with a biarch arrangement)?</li>
+ <li>Are there 3 or more developers (or NMs) actively maintaining
+ the port? Who are they?</li>
+ <li>What sort of architecture is this? Desktop/workstation?
+ Mainframe/supercomputer? Embedded? Something else?</li>
+ <li>Does it have any users? If a desktop system, are there Debian
+ admins who run Debian systems on the arch? If an embedded system
+ are there real systems shipping that a Debian port will be useful
+ for? If a mainframe system are there real systems with many users
+ that a Debian port will be useful for? Who are they?</li>
+ <li>Is there kernel and toolchain support? At what level? Are the
+ latest versions supported, or are legacy releases required for
+ compatability with some hardware?</li>
+ <li>Has the ABI stabalised, or are there major ABI changes coming
+ up? Is the ABI stable enough to ensure users will be able just
+ "apt-get dist-upgrade" from one version to the next?</li>
+ <li>How do you install a system? (URL to a HOWTO)</li>
+ <li>Has a buildd been setup? How much of the archive has been
+ built (count by source package, builds of old versions are fine
+ for this case)?</li>
+ <li>What hardware is potentially available as a fast buildd?</li>
+ <li>Is there an example box developers can login to to see if it
+ works?</li>
+ </ul>
+
+ <p>It's also worth considering whether the port has any special
+ requirements. If the port is mainly for embedded systems, it may be
+ appropriate to have different installation or release arrangements
+ compared to normal desktop/workstation architectures.</p>
+
+ <h1>Further questions for OSes</h1>
+
+ <ul>
+ <li>Are there existing comprehensive free distributions of this OS? If
+ so, why is a Debian distribution useful?</li>
+ <li>What demonstrable benefits does this OS have over existing
+ Debian OSes?</li>
+ <li>Does this system have a standard Unix API?</li>
+ <li>Does the OS support modern glibc and gcc?</li>
+ <li>What is the license on the kernel and core libraries? Is the license
+ free? Is the license GPL compatible? (Note that if it's not free, distributing
+ the software violates the Social Contract; and if it's not GPL compatible,
+ GPL software such as dpkg can't be linked to it)</li>
+ <li>Does the OS build largely without source changes? If so, what proportion of
+ the archive has built?</li>
+ </ul>
+
+ <p>It's worth thinking about whether it makes sense to integrate the
+ port with Debian's Linux-based distribution -- having separate sources
+ may not only reduce the impact on the release architectures, but also
+ make it easier to do development on the new OS as well.</p>
+
+ <p>Note that if significant changes are needed to more than just a small
+ number of packages, your porting team will not only need to provide
+ patches for most of those changes and make sure they work, but also
+ ensure they don't cause problems for existing ports.</p>
+
+
+ <div class="footer">
+ <p>
+ <a href="http://validator.w3.org/check?uri=referer"><img src="http://www.w3.org/Icons/valid-xhtml10"
+ alt="Valid XHTML 1.0 Strict" height="31" width="88" /></a>
+ <a href="http://jigsaw.w3.org/css-validator/">
+ <img style="border:0;width:88px;height:31px" src="http://jigsaw.w3.org/css-validator/images/vcss"
+ alt="Valid CSS!" />
+ </a>
+ </p>
+ </div> </body> </html>
projects / dak.git / commitdiff