aboutsummaryrefslogtreecommitdiffhomepage
path: root/debian
diff options
context:
space:
mode:
Diffstat (limited to 'debian')
-rw-r--r--debian/bin/sisu137
-rw-r--r--debian/bin/sisu2137
-rw-r--r--debian/bin/sisu3137
-rw-r--r--debian/bin/sisu_termsheet159
-rw-r--r--debian/bin/sisu_webrick146
-rw-r--r--debian/changelog5056
-rw-r--r--debian/compat1
-rw-r--r--debian/control121
-rw-r--r--debian/copyright91
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/_sisu/skin/doc/skin_debian.rb83
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2.adjusted.sst502
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2.sst499
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2~da.sst501
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2~de.sst503
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2~es.sst517
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2~fr.sst508
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.3.adjusted.sst506
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.3.sst507
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.3~da.sst514
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.3~de.sst503
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1.sst136
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~da.sst138
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~de.sst139
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~es.sst136
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~fi.sst138
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~fr.sst136
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~it.sst128
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/_sisu/skin/doc/skin_debian.rb83
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/da/debian_constitution_v1.2.sst501
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/da/debian_constitution_v1.3.sst514
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/da/debian_social_contract_v1.1.sst138
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/de/debian_constitution_v1.2.sst503
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/de/debian_constitution_v1.3.sst503
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/de/debian_social_contract_v1.1.sst139
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/en/debian_constitution_v1.2.adjusted.sst502
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/en/debian_constitution_v1.2.sst499
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/en/debian_constitution_v1.3.adjusted.sst506
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/en/debian_constitution_v1.3.sst507
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/en/debian_social_contract_v1.1.sst136
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/es/debian_constitution_v1.2.sst517
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/es/debian_social_contract_v1.1.sst136
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/fi/debian_social_contract_v1.1.sst138
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/fr/debian_constitution_v1.2.sst508
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/fr/debian_social_contract_v1.1.sst136
-rw-r--r--debian/data/doc/sisu/markup-samples/samples/v3/it/debian_social_contract_v1.1.sst127
-rw-r--r--debian/manpages/sisu-complete.732
-rw-r--r--debian/manpages/sisu-pdf.732
-rw-r--r--debian/manpages/sisu-postgresql.734
-rw-r--r--debian/manpages/sisu-sqlite.734
-rwxr-xr-xdebian/rules10
-rw-r--r--debian/sisu-complete.manpages1
-rw-r--r--debian/sisu-pdf.install1
-rw-r--r--debian/sisu-pdf.manpages2
-rw-r--r--debian/sisu-postgresql.install1
-rw-r--r--debian/sisu-postgresql.manpages2
-rw-r--r--debian/sisu-sqlite.install1
-rw-r--r--debian/sisu-sqlite.manpages2
-rw-r--r--debian/sisu.NEWS.Debian107
-rw-r--r--debian/sisu.docs1
-rw-r--r--debian/sisu.install27
-rw-r--r--debian/sisu.lintian-overrides12
-rw-r--r--debian/sisu.manpages14
-rw-r--r--debian/source/format1
-rw-r--r--debian/source/options1
-rw-r--r--debian/watch2
65 files changed, 18489 insertions, 0 deletions
diff --git a/debian/bin/sisu b/debian/bin/sisu
new file mode 100644
index 00000000..3b31da19
--- /dev/null
+++ b/debian/bin/sisu
@@ -0,0 +1,137 @@
+#! /usr/bin/ruby1.9.1
+# encoding: utf-8
+#SiSU: copyright (C) 1997 - 2012 Ralph Amissah; License GPL, see appended program information
+begin
+ def ruby_version_ok?(base_version)
+ @v ||=RUBY_VERSION.scan(/\d+/)
+ vb=base_version.scan(/\d+/)
+ if @v[0].to_i < vb[0].to_i \
+ or @v[0].to_i == vb[0].to_i \
+ && @v[1].to_i < vb[1].to_i \
+ or @v[0].to_i == vb[0].to_i \
+ && @v[1].to_i == vb[1].to_i \
+ && @v[1].to_i < vb[2].to_i
+ raise "Please, use Ruby#{vb} or later, current Ruby #{RUBY_VERSION}"
+ else check_incompatible_ruby_build?
+ end
+ end
+ def check_incompatible_ruby_build?
+ require 'rbconfig'
+ e=Config::CONFIG
+ if RUBY_VERSION == '1.9.2' \
+ && e['PATCHLEVEL'].to_i < 180
+ raise <<WOK
+There are known issues with early versions of ruby1.9.2.
+Please, use Ruby 1.9.2p180 or later,
+current version #{e['RUBY_PROGRAM_VERSION']}p#{e['PATCHLEVEL']}
+#{%x{ruby -v}.strip.to_s}
+
+WOK
+ end
+ end
+ def check_sisu_legacy_ruby_version?
+ rbv_sisu_legacy='1.9.2' #'1.8.7'
+ ruby_version_ok?(rbv_sisu_legacy)
+ end
+ def check_sisu_stable_ruby_version?
+ rbv_sisu_stable='1.9.2'
+ ruby_version_ok?(rbv_sisu_stable)
+ end
+ def check_sisu_dev_ruby_version?
+ rbv_sisu_dev='1.9.2'
+ ruby_version_ok?(rbv_sisu_dev)
+ end
+ $VERBOSE=nil
+ $KCODE='u' if RUBY_VERSION < '1.9'
+ argv=$*
+ SiSU_version_dir=case argv.inspect
+ when /--v2/
+ check_sisu_legacy_ruby_version?
+ 'v2'
+ when /--v3/
+ check_sisu_stable_ruby_version?
+ 'v3'
+ when /--dev/
+ check_sisu_dev_ruby_version?
+ 'v3' #'v3dv'
+ else
+ check_sisu_stable_ruby_version?
+ 'v3'
+ end
+ SiSU_lib="sisu/#{SiSU_version_dir}"
+ require "#{SiSU_lib}/hub"
+rescue
+ STDERR.puts 'ERROR'
+ STDERR.puts $!
+ STDERR.puts $@
+ require 'rbconfig'
+ e=Config::CONFIG
+ puts %{
+ #{%x{ruby -v}.strip.to_s}
+ #{RUBY_VERSION}
+ ruby version: #{e['RUBY_PROGRAM_VERSION']}p#{e['PATCHLEVEL']}
+ ruby named: #{e['ruby_version']}
+ rubylib: #{e['rubylibdir']}
+ rubylib local: #{e['sitelibdir']}
+ }
+ system(%{echo "
+ system RUBYPATH: ${RUBYPATH}
+ system RUBYLIB: ${RUBYLIB}
+ "})
+ puts %{
+ On a Debian system to switch the version of ruby to >=1.9.2 see:
+ http://wiki.debian.org/Ruby
+ }
+end
+__END__
+
+ * Name: SiSU
+
+ * Description: a framework for document structuring, publishing and search
+
+ * Author: Ralph Amissah
+
+ * Copyright: (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006,
+ 2007, 2008, 2009, 2010, 2011, 2012 Ralph Amissah, All Rights Reserved.
+
+ * License: GPL 3 or later:
+
+ SiSU, a framework for document structuring, publishing and search
+
+ Copyright (C) Ralph Amissah
+
+ 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 the Free
+ Software Foundation, either version 3 of the License, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program. If not, see <http://www.gnu.org/licenses/>.
+
+ If you have Internet connection, the latest version of the GPL should be
+ available at these locations:
+ <http://www.fsf.org/licensing/licenses/gpl.html>
+ <http://www.gnu.org/licenses/gpl.html>
+
+ <http://www.sisudoc.org/sisu/en/manifest/gpl.fsf.html>
+
+ * SiSU uses:
+ * Standard SiSU markup syntax,
+ * Standard SiSU meta-markup syntax, and the
+ * Standard SiSU object citation numbering and system
+
+ * Hompages:
+ <http://www.jus.uio.no/sisu>
+ <http://www.sisudoc.org>
+
+ * Download:
+ <http://www.sisudoc.org/sisu/en/SiSU/download.html>
+
+ * Ralph Amissah
+ <ralph@amissah.com>
+ <ralph.amissah@gmail.com>
diff --git a/debian/bin/sisu2 b/debian/bin/sisu2
new file mode 100644
index 00000000..9c52163c
--- /dev/null
+++ b/debian/bin/sisu2
@@ -0,0 +1,137 @@
+#! /usr/bin/ruby1.9.1
+# encoding: utf-8
+#SiSU: copyright (C) 1997 - 2011 Ralph Amissah; License GPL, see appended program information
+begin
+ def ruby_version_ok?(base_version)
+ @v ||=RUBY_VERSION.scan(/\d+/)
+ vb=base_version.scan(/\d+/)
+ if @v[0].to_i < vb[0].to_i \
+ or @v[0].to_i == vb[0].to_i \
+ && @v[1].to_i < vb[1].to_i \
+ or @v[0].to_i == vb[0].to_i \
+ && @v[1].to_i == vb[1].to_i \
+ && @v[1].to_i < vb[2].to_i
+ raise "Please, use Ruby#{vb} or later, current Ruby #{RUBY_VERSION}"
+ else check_incompatible_ruby_build?
+ end
+ end
+ def check_incompatible_ruby_build?
+ require 'rbconfig'
+ e=Config::CONFIG
+ if RUBY_VERSION == '1.9.2' \
+ && e['PATCHLEVEL'].to_i < 180
+ raise <<WOK
+There are known issues with early versions of ruby1.9.2.
+Please, use Ruby 1.9.2p180 or later,
+current version #{e['RUBY_PROGRAM_VERSION']}p#{e['PATCHLEVEL']}
+#{%x{ruby -v}.strip.to_s}
+
+WOK
+ end
+ end
+ def check_sisu_legacy_ruby_version?
+ rbv_sisu_legacy='1.9.2' #'1.8.7'
+ ruby_version_ok?(rbv_sisu_legacy)
+ end
+ def check_sisu_stable_ruby_version?
+ rbv_sisu_stable='1.9.2'
+ ruby_version_ok?(rbv_sisu_stable)
+ end
+ def check_sisu_dev_ruby_version?
+ rbv_sisu_dev='1.9.2'
+ ruby_version_ok?(rbv_sisu_dev)
+ end
+ $VERBOSE=nil
+ $KCODE='u' if RUBY_VERSION < '1.9'
+ argv=$*
+ SiSU_version_dir=case argv.inspect
+ when /--v2/
+ check_sisu_legacy_ruby_version?
+ 'v2'
+ when /--v3/
+ check_sisu_stable_ruby_version?
+ 'v3'
+ when /--dev/
+ check_sisu_dev_ruby_version?
+ 'v3' #'v3dv'
+ else
+ check_sisu_stable_ruby_version?
+ 'v3'
+ end
+ SiSU_lib="sisu/#{SiSU_version_dir}"
+ require "#{SiSU_lib}/hub"
+rescue
+ STDERR.puts 'ERROR'
+ STDERR.puts $!
+ STDERR.puts $@
+ require 'rbconfig'
+ e=Config::CONFIG
+ puts %{
+ #{%x{ruby -v}.strip.to_s}
+ #{RUBY_VERSION}
+ ruby version: #{e['RUBY_PROGRAM_VERSION']}p#{e['PATCHLEVEL']}
+ ruby named: #{e['ruby_version']}
+ rubylib: #{e['rubylibdir']}
+ rubylib local: #{e['sitelibdir']}
+ }
+ system(%{echo "
+ system RUBYPATH: ${RUBYPATH}
+ system RUBYLIB: ${RUBYLIB}
+ "})
+ puts %{
+ On a Debian system to switch the version of ruby to >=1.9.2 see:
+ http://wiki.debian.org/Ruby
+ }
+end
+__END__
+
+ * Name: SiSU
+
+ * Description: a framework for document structuring, publishing and search
+
+ * Author: Ralph Amissah
+
+ * Copyright: (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006,
+ 2007, 2008, 2009, 2010, 2011, 2012 Ralph Amissah, All Rights Reserved.
+
+ * License: GPL 3 or later:
+
+ SiSU, a framework for document structuring, publishing and search
+
+ Copyright (C) Ralph Amissah
+
+ 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 the Free
+ Software Foundation, either version 3 of the License, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program. If not, see <http://www.gnu.org/licenses/>.
+
+ If you have Internet connection, the latest version of the GPL should be
+ available at these locations:
+ <http://www.fsf.org/licensing/licenses/gpl.html>
+ <http://www.gnu.org/licenses/gpl.html>
+
+ <http://www.sisudoc.org/sisu/en/manifest/gpl.fsf.html>
+
+ * SiSU uses:
+ * Standard SiSU markup syntax,
+ * Standard SiSU meta-markup syntax, and the
+ * Standard SiSU object citation numbering and system
+
+ * Hompages:
+ <http://www.jus.uio.no/sisu>
+ <http://www.sisudoc.org>
+
+ * Download:
+ <http://www.sisudoc.org/sisu/en/SiSU/download.html>
+
+ * Ralph Amissah
+ <ralph@amissah.com>
+ <ralph.amissah@gmail.com>
diff --git a/debian/bin/sisu3 b/debian/bin/sisu3
new file mode 100644
index 00000000..3b31da19
--- /dev/null
+++ b/debian/bin/sisu3
@@ -0,0 +1,137 @@
+#! /usr/bin/ruby1.9.1
+# encoding: utf-8
+#SiSU: copyright (C) 1997 - 2012 Ralph Amissah; License GPL, see appended program information
+begin
+ def ruby_version_ok?(base_version)
+ @v ||=RUBY_VERSION.scan(/\d+/)
+ vb=base_version.scan(/\d+/)
+ if @v[0].to_i < vb[0].to_i \
+ or @v[0].to_i == vb[0].to_i \
+ && @v[1].to_i < vb[1].to_i \
+ or @v[0].to_i == vb[0].to_i \
+ && @v[1].to_i == vb[1].to_i \
+ && @v[1].to_i < vb[2].to_i
+ raise "Please, use Ruby#{vb} or later, current Ruby #{RUBY_VERSION}"
+ else check_incompatible_ruby_build?
+ end
+ end
+ def check_incompatible_ruby_build?
+ require 'rbconfig'
+ e=Config::CONFIG
+ if RUBY_VERSION == '1.9.2' \
+ && e['PATCHLEVEL'].to_i < 180
+ raise <<WOK
+There are known issues with early versions of ruby1.9.2.
+Please, use Ruby 1.9.2p180 or later,
+current version #{e['RUBY_PROGRAM_VERSION']}p#{e['PATCHLEVEL']}
+#{%x{ruby -v}.strip.to_s}
+
+WOK
+ end
+ end
+ def check_sisu_legacy_ruby_version?
+ rbv_sisu_legacy='1.9.2' #'1.8.7'
+ ruby_version_ok?(rbv_sisu_legacy)
+ end
+ def check_sisu_stable_ruby_version?
+ rbv_sisu_stable='1.9.2'
+ ruby_version_ok?(rbv_sisu_stable)
+ end
+ def check_sisu_dev_ruby_version?
+ rbv_sisu_dev='1.9.2'
+ ruby_version_ok?(rbv_sisu_dev)
+ end
+ $VERBOSE=nil
+ $KCODE='u' if RUBY_VERSION < '1.9'
+ argv=$*
+ SiSU_version_dir=case argv.inspect
+ when /--v2/
+ check_sisu_legacy_ruby_version?
+ 'v2'
+ when /--v3/
+ check_sisu_stable_ruby_version?
+ 'v3'
+ when /--dev/
+ check_sisu_dev_ruby_version?
+ 'v3' #'v3dv'
+ else
+ check_sisu_stable_ruby_version?
+ 'v3'
+ end
+ SiSU_lib="sisu/#{SiSU_version_dir}"
+ require "#{SiSU_lib}/hub"
+rescue
+ STDERR.puts 'ERROR'
+ STDERR.puts $!
+ STDERR.puts $@
+ require 'rbconfig'
+ e=Config::CONFIG
+ puts %{
+ #{%x{ruby -v}.strip.to_s}
+ #{RUBY_VERSION}
+ ruby version: #{e['RUBY_PROGRAM_VERSION']}p#{e['PATCHLEVEL']}
+ ruby named: #{e['ruby_version']}
+ rubylib: #{e['rubylibdir']}
+ rubylib local: #{e['sitelibdir']}
+ }
+ system(%{echo "
+ system RUBYPATH: ${RUBYPATH}
+ system RUBYLIB: ${RUBYLIB}
+ "})
+ puts %{
+ On a Debian system to switch the version of ruby to >=1.9.2 see:
+ http://wiki.debian.org/Ruby
+ }
+end
+__END__
+
+ * Name: SiSU
+
+ * Description: a framework for document structuring, publishing and search
+
+ * Author: Ralph Amissah
+
+ * Copyright: (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006,
+ 2007, 2008, 2009, 2010, 2011, 2012 Ralph Amissah, All Rights Reserved.
+
+ * License: GPL 3 or later:
+
+ SiSU, a framework for document structuring, publishing and search
+
+ Copyright (C) Ralph Amissah
+
+ 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 the Free
+ Software Foundation, either version 3 of the License, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program. If not, see <http://www.gnu.org/licenses/>.
+
+ If you have Internet connection, the latest version of the GPL should be
+ available at these locations:
+ <http://www.fsf.org/licensing/licenses/gpl.html>
+ <http://www.gnu.org/licenses/gpl.html>
+
+ <http://www.sisudoc.org/sisu/en/manifest/gpl.fsf.html>
+
+ * SiSU uses:
+ * Standard SiSU markup syntax,
+ * Standard SiSU meta-markup syntax, and the
+ * Standard SiSU object citation numbering and system
+
+ * Hompages:
+ <http://www.jus.uio.no/sisu>
+ <http://www.sisudoc.org>
+
+ * Download:
+ <http://www.sisudoc.org/sisu/en/SiSU/download.html>
+
+ * Ralph Amissah
+ <ralph@amissah.com>
+ <ralph.amissah@gmail.com>
diff --git a/debian/bin/sisu_termsheet b/debian/bin/sisu_termsheet
new file mode 100644
index 00000000..7a3b0425
--- /dev/null
+++ b/debian/bin/sisu_termsheet
@@ -0,0 +1,159 @@
+#! /usr/bin/ruby1.9.1
+# encoding: utf-8
+#SiSU: copyright (C) 1997 - 2012 Ralph Amissah; License GPL, see appended program information
+begin
+ def ruby_version_ok?(base_version)
+ @v ||=RUBY_VERSION.scan(/\d+/)
+ vb=base_version.scan(/\d+/)
+ if @v[0].to_i < vb[0].to_i \
+ or @v[0].to_i == vb[0].to_i \
+ && @v[1].to_i < vb[1].to_i \
+ or @v[0].to_i == vb[0].to_i \
+ && @v[1].to_i == vb[1].to_i \
+ && @v[1].to_i < vb[2].to_i
+ raise "Please, use Ruby#{vb} or later, current Ruby #{RUBY_VERSION}"
+ else check_incompatible_ruby_build?
+ end
+ end
+ def check_incompatible_ruby_build?
+ require 'rbconfig'
+ e=Config::CONFIG
+ if RUBY_VERSION == '1.9.2' \
+ && e['PATCHLEVEL'].to_i < 180
+ raise <<WOK
+There are known issues with early versions of ruby1.9.2.
+Please, use Ruby 1.9.2p180 or later,
+current version #{e['RUBY_PROGRAM_VERSION']}p#{e['PATCHLEVEL']}
+#{%x{ruby -v}.strip.to_s}
+
+WOK
+ end
+ end
+ def check_sisu_legacy_ruby_version?
+ rbv_sisu_legacy='1.9.2' #'1.8.7'
+ ruby_version_ok?(rbv_sisu_legacy)
+ end
+ def check_sisu_stable_ruby_version?
+ rbv_sisu_stable='1.9.2'
+ ruby_version_ok?(rbv_sisu_stable)
+ end
+ def check_sisu_dev_ruby_version?
+ rbv_sisu_dev='1.9.2'
+ ruby_version_ok?(rbv_sisu_dev)
+ end
+ $VERBOSE=nil
+ argv=$*
+ SiSU_version_dir=case argv.inspect
+ when /--v2/
+ check_sisu_legacy_ruby_version?
+ 'v2'
+ when /--v3/
+ check_sisu_stable_ruby_version?
+ 'v3'
+ when /--dev/
+ check_sisu_dev_ruby_version?
+ 'v3' #'v3dv'
+ else
+ check_sisu_stable_ruby_version?
+ 'v3'
+ end
+ SiSU_lib="sisu/#{SiSU_version_dir}"
+ require "#{SiSU_lib}/termsheet"
+rescue
+ STDERR.puts 'ERROR'
+ STDERR.puts $!
+ STDERR.puts $@
+ require 'rbconfig'
+ e=Config::CONFIG
+ puts %{
+ #{%x{ruby -v}.strip.to_s}
+ #{RUBY_VERSION}
+ ruby version: #{e['RUBY_PROGRAM_VERSION']}p#{e['PATCHLEVEL']}
+ ruby named: #{e['ruby_version']}
+ rubylib: #{e['rubylibdir']}
+ rubylib local: #{e['sitelibdir']}
+ }
+ system(%{echo "
+ system RUBYPATH: ${RUBYPATH}
+ system RUBYLIB: ${RUBYLIB}
+ "})
+ puts %{
+ On a Debian system the following system commands may help set the default version of ruby to 1.9.2:
+ sudo update-alternatives --verbose --set ruby /usr/bin/ruby1.9.1
+ export RUBYPATH='/usr/local/bin:/usr/bin'
+ export RUBYLIB='/usr/local/lib/site_ruby/1.9.1:/usr/lib/ruby/1.9.1:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8'
+
+ To return to ruby 1.8 (not suitable for sisu):
+ sudo update-alternatives --verbose --set ruby /usr/bin/ruby1.8
+ export RUBYPATH='/usr/local/bin'
+ export RUBYLIB='/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8:/usr/local/lib/site_ruby/1.9.1:/usr/lib/ruby/1.9.1'
+ }
+end
+__END__
+
+ * Name: SiSU
+
+ * Description: a framework for document structuring, publishing and search
+
+ * Author: Ralph Amissah
+
+ * Copyright: (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006,
+ 2007, 2008, 2009, 2010, 2011, 2012 Ralph Amissah, All Rights Reserved.
+
+ * License: GPL 3 or later:
+
+ SiSU, a framework for document structuring, publishing and search
+
+ Copyright (C) Ralph Amissah
+
+ 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 the Free
+ Software Foundation, either version 3 of the License, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program. If not, see <http://www.gnu.org/licenses/>.
+
+ If you have Internet connection, the latest version of the GPL should be
+ available at these locations:
+ <http://www.fsf.org/licensing/licenses/gpl.html>
+ <http://www.gnu.org/licenses/gpl.html>
+
+ <http://www.sisudoc.org/sisu/en/manifest/gpl.fsf.html>
+
+ * SiSU uses:
+ * Standard SiSU markup syntax,
+ * Standard SiSU meta-markup syntax, and the
+ * Standard SiSU object citation numbering and system
+
+ * Hompages:
+ <http://www.jus.uio.no/sisu>
+ <http://www.sisudoc.org>
+
+ * Download:
+ <http://www.sisudoc.org/sisu/en/SiSU/download.html>
+
+ * Ralph Amissah
+ <ralph@amissah.com>
+ <ralph.amissah@gmail.com>
+
+ ** Description: SiSU information Structuring Universe, specialised
+ pre-processing wrapper
+
+ sisu -t x_bank.and.*
+ e.g. sisu -t x_bank.and.*.termsheet.rb
+ e.g. sisu_termsheet.rb -t x_bank.and.c*.termsheet.rb
+ program calls upon termsheet file with extension termsheet.rb
+ termsheet.rb calls upon relevant standard form files (to be used) with extension .sForm.rb
+ there is also a standard_terms.rb file - with terms/details that are constant
+ the file produced is named after the termsheet.rb with that extension replaced with .er30
+ from there scribbler.rb is called upon its usual metaVerse html and pdf creation
+ ! :-)
+ to test run
+ termsheet.rb -f dev.export.import.trade.facility.termsheet.rb
+ the term sheet calls the standard form or template that is to be run against it.
diff --git a/debian/bin/sisu_webrick b/debian/bin/sisu_webrick
new file mode 100644
index 00000000..b678d029
--- /dev/null
+++ b/debian/bin/sisu_webrick
@@ -0,0 +1,146 @@
+#! /usr/bin/ruby1.9.1
+# encoding: utf-8
+#SiSU: copyright (C) 1997 - 2012 Ralph Amissah; License GPL, see appended program information
+begin
+ def ruby_version_ok?(base_version)
+ @v ||=RUBY_VERSION.scan(/\d+/)
+ vb=base_version.scan(/\d+/)
+ if @v[0].to_i < vb[0].to_i \
+ or @v[0].to_i == vb[0].to_i \
+ && @v[1].to_i < vb[1].to_i \
+ or @v[0].to_i == vb[0].to_i \
+ && @v[1].to_i == vb[1].to_i \
+ && @v[1].to_i < vb[2].to_i
+ raise "Please, use Ruby#{vb} or later, current Ruby #{RUBY_VERSION}"
+ else check_incompatible_ruby_build?
+ end
+ end
+ def check_incompatible_ruby_build?
+ require 'rbconfig'
+ e=Config::CONFIG
+ if RUBY_VERSION == '1.9.2' \
+ && e['PATCHLEVEL'].to_i < 180
+ raise <<WOK
+There are known issues with early versions of ruby1.9.2.
+Please, use Ruby 1.9.2p180 or later,
+current version #{e['RUBY_PROGRAM_VERSION']}p#{e['PATCHLEVEL']}
+#{%x{ruby -v}.strip.to_s}
+
+WOK
+ end
+ end
+ def check_sisu_legacy_ruby_version?
+ rbv_sisu_legacy='1.9.2' #'1.8.7'
+ ruby_version_ok?(rbv_sisu_legacy)
+ end
+ def check_sisu_stable_ruby_version?
+ rbv_sisu_stable='1.9.2'
+ ruby_version_ok?(rbv_sisu_stable)
+ end
+ def check_sisu_dev_ruby_version?
+ rbv_sisu_dev='1.9.2'
+ ruby_version_ok?(rbv_sisu_dev)
+ end
+ $VERBOSE=nil
+ argv=$*
+ SiSU_version_dir=case argv.inspect
+ when /--v2/
+ check_sisu_legacy_ruby_version?
+ 'v2'
+ when /--v3/
+ check_sisu_stable_ruby_version?
+ 'v3'
+ when /--dev/
+ check_sisu_dev_ruby_version?
+ 'v3' #'v3dv'
+ else
+ check_sisu_stable_ruby_version?
+ 'v3'
+ end
+ SiSU_lib="sisu/#{SiSU_version_dir}"
+ require "#{SiSU_lib}/webrick"
+rescue
+ STDERR.puts 'ERROR'
+ STDERR.puts $!
+ STDERR.puts $@
+ require 'rbconfig'
+ e=Config::CONFIG
+ puts %{
+ #{%x{ruby -v}.strip.to_s}
+ #{RUBY_VERSION}
+ ruby version: #{e['RUBY_PROGRAM_VERSION']}p#{e['PATCHLEVEL']}
+ ruby named: #{e['ruby_version']}
+ rubylib: #{e['rubylibdir']}
+ rubylib local: #{e['sitelibdir']}
+ }
+ system(%{echo "
+ system RUBYPATH: ${RUBYPATH}
+ system RUBYLIB: ${RUBYLIB}
+ "})
+ puts %{
+ On a Debian system the following system commands may help set the default version of ruby to 1.9.2:
+ sudo update-alternatives --verbose --set ruby /usr/bin/ruby1.9.1
+ export RUBYPATH='/usr/local/bin:/usr/bin'
+ export RUBYLIB='/usr/local/lib/site_ruby/1.9.1:/usr/lib/ruby/1.9.1:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8'
+
+ To return to ruby 1.8 (not suitable for sisu):
+ sudo update-alternatives --verbose --set ruby /usr/bin/ruby1.8
+ export RUBYPATH='/usr/local/bin'
+ export RUBYLIB='/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8:/usr/local/lib/site_ruby/1.9.1:/usr/lib/ruby/1.9.1'
+ }
+end
+__END__
+
+ * Name: SiSU
+
+ * Description: a framework for document structuring, publishing and search
+
+ * Author: Ralph Amissah
+
+ * Copyright: (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006,
+ 2007, 2008, 2009, 2010, 2011, 2012 Ralph Amissah, All Rights Reserved.
+
+ * License: GPL 3 or later:
+
+ SiSU, a framework for document structuring, publishing and search
+
+ Copyright (C) Ralph Amissah
+
+ 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 the Free
+ Software Foundation, either version 3 of the License, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program. If not, see <http://www.gnu.org/licenses/>.
+
+ If you have Internet connection, the latest version of the GPL should be
+ available at these locations:
+ <http://www.fsf.org/licensing/licenses/gpl.html>
+ <http://www.gnu.org/licenses/gpl.html>
+
+ <http://www.sisudoc.org/sisu/en/manifest/gpl.fsf.html>
+
+ * SiSU uses:
+ * Standard SiSU markup syntax,
+ * Standard SiSU meta-markup syntax, and the
+ * Standard SiSU object citation numbering and system
+
+ * Hompages:
+ <http://www.jus.uio.no/sisu>
+ <http://www.sisudoc.org>
+
+ * Download:
+ <http://www.sisudoc.org/sisu/en/SiSU/download.html>
+
+ * Ralph Amissah
+ <ralph@amissah.com>
+ <ralph.amissah@gmail.com>
+
+ ** Description: webrick share - note sisu by default does not link with file
+ suffixes, see man pages for options
diff --git a/debian/changelog b/debian/changelog
new file mode 100644
index 00000000..00b63ff8
--- /dev/null
+++ b/debian/changelog
@@ -0,0 +1,5056 @@
+sisu (3.3.3-1) unstable; urgency=low
+
+ * [cbe9698] sha256 (3.3.2)
+ * [c2f44d3] v3: 3.3.3 version & changelog "opened"
+ * [1d40176] v3: constants, year static (current): YEAR=2012
+ * [8f9076f] v3: sisu -v, provide version information, fix
+ * [b469460] v3: bin/sisu, hub, reorganize call
+ * [662cd26] v3: some pre-unicode meddling sorted
+ * covers bug reported as middle dot changed to asterisk by chals
+ * [dd13f63] v3: dbi, pgsql, report need for instructions when none given
+ * [2ea56a4] v3: sisupod source, paths fix
+ * [7856672] v3: options, opt_act, limit calls
+ * ruby profiler indicates much time spent here, reduce
+ * [f90e9b2] v3: pdflatex, landscape cover page was botched, came out as
+ portrait, fix
+ * [d96753b] v3: texpdf fixes
+ * group text, bullet
+ * group text, hardspaces at start of line (indent)
+ * group text, pass through special characters safe
+ * poem, bold etc.
+ * [e5fe055] v3: html, epub, group text, bullet, fix
+ * [ef4da2e] v3: dal_syntax, new syntax: =\\= page new & -\\- page break
+ * alias for <:pn> and <:pb> respectively
+ * [b553ca8] v3: vim syntax, sisu.vim, =\\= page new & -\\- page break
+ * [58c13f4] v3: odf, internal links/bookmarks, toc, book index
+ * [ad6cf3c] v3: vim, ftplugin/sisu.vim
+ * linenumbering: on; relative; off, <leader>nn
+ * cursor line & column: on; off, <leader>cu (existing cu+ & cu-)
+ * [7d4665f] v3: cosmetic code, true ? x : y
+ * [02cc96f] v3: cosmetic code, if, else, remove some semicolons (;) replace
+ with newlines
+ * [32d32bf] v3: cosmetic code, if true ; x, remove semicolons replace with
+ "then"
+ * [6b2c447] v3: cosmetic code, .is_a?(X) replaces .class==X (& some defined? &
+ nil? tests)
+ * [5e1bcfb] v3: cosmetic code, remove javascript holders js_ (not used)
+ * [d98f270] v3: some fixes, cleaning, removing
+ * [52e870e] v3: dal, sysenv, file processing, split objects; remove ref to old
+ ruby
+ * markup file processing, change to sourcefile readlines & split of
+ sourcefile array
+ * removal of RUBY_VERSION references to older versions of ruby
+ * [d6ef30b] v3: header @classify: :topic_register: provide greater
+ classification "depth"
+ * param, manifest
+ * harvest_topics
+ * [8e40c8f] v3: db, book_idx field & minor re-arrangement
+ * [610573c] v3: cgi search script, minor
+ * [78b7033] v3: markup samples, and help, minor updates
+ * [f08ab38] v3: 3.3.3 version & changelog, dates touched
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 12 Dec 2012 15:00:32 -0500
+
+sisu (3.3.2-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [22a2200] sha256 (3.3.1)
+ * [6c8cd33] v3: 3.3.2 version & changelog "opened"
+ * [a1a1c16] v3: texpdf, xetex screen reporting of warnings off unless
+ sisu -pV used
+ * [6158b22] debian/rules debian/source/options use xz compression instead of
+ gzip
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 30 Jun 2012 00:47:28 -0400
+
+sisu (3.3.1-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [7e27b55] sha256 (3.3.0)
+ * [1de02aa] v3: 3.3.1 version & changelog "opened"
+ * [ffb9960] v3: hub, some re-arrangement
+ * [55e1f9c] v3: texpdf_format, urls in headings break pdf documents, fix
+ * e.g. output generation of document sample gpl.fsf.sst pdf fixed
+ * [990bafc] v3: sysenv, rsync put (post to remote site), fix, needs
+ comprehensive check
+ * broken since version 3 (did not cope with alternative output structures,
+ initial fix
+ * still broken:
+ * rsync get (sisu source);
+ * scp put & scp get)
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 23 Jun 2012 02:15:47 -0400
+
+sisu (3.3.0-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * [0cda363] sha256 (3.2.12)
+ * [12adefb] v3: 3.3.0 version & changelog "opened"
+ * [fed01af] v3: shared_sisupod_source, common build for sisu (markup) source
+ representations
+ * to be used by sisupod.txz, git, (and src)
+ * sisupod_make (--sisupod)
+ * share_source (--source)
+ NOTE not used git at present
+ * changed representation of shared sisu source, include related files in
+ directory rather than just markup file [reason for version bump]
+ NOTE there are no changes to sisu markup (only the sharing of source
+ files)
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 17 Jun 2012 22:55:34 -0400
+
+sisu (3.2.12-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * [64bd821] sha256 (3.2.11)
+ * [0919395] v3: 3.2.12 version & changelog "opened"
+ * [b5323c8] Rake, Rant sisu installer require ruby >= 1.9.3
+ * [dd790c7] v3: dbi_discreet, screen reporting db location, fix
+ * [6715da8] v3: shared_images, fix
+ * [3c8feda] v3: screen reporting, ansi colors, cosmetic
+ * [1e089ff] v3: html, excludes (options) --exc-html-top-band, touch
+ * html (toc & scroll), (html_segments, concordance,) exclude top band
+ sisu --exc-top-band --html --concordance filename.sst
+ * [7b13cb9] v3: html_segments, @make.build.html_navigation?, fix, (excludes
+ --exc-html-)
+ * [3ca890e] v3: sysenv, check @md.make.respond_to?(:skin)
+ * [c8d6617] v3: hub, post bundles, sisupod_make, file selection selection for
+ tar.xz, fix
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 06 Jun 2012 23:55:46 -0400
+
+sisu (3.2.11-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * [e48ecd9] sha256 (3.2.10)
+ * [c3a4d65] v3: 3.2.11 version & changelog "opened"
+ * [2cd635d] v3: error & warning messages touched, revisit
+ * [33417c5] v3: warn when files to be copied not found, add
+ * [9c234e6] v3: urls, sisupod, fix
+ * [a887643] v3: manifest, paths, (for command line selection of output type)
+ fix
+ * [26e5e47] v3: images, regular & sisupod
+ * [35e3bca] v3: images, copy (system link removed)
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 03 Jun 2012 22:33:49 -0400
+
+sisu (3.2.10-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * [220350d] sha256 (3.2.9)
+ * [8cc2ed9] v3: 3.2.10 version & changelog "opened"
+ * [965fe1f] v3: code headers mainly copyright
+ * [308733d] debian/bin: code headers mainly copyright
+ * [23a9053] v3: hub, "requires", fix
+ * [6e6602f] v3: options, --init-site, --configure, fix
+ * [ba278b9] v3: options, command line control of output directory structure
+ * --output-by-language; --output-by-filetype; --output-by-filename, or
+ --by-language; --by-filetype; --by-filename
+ * [3faa85c] v3: documentation update, command line control of output dir
+ structure
+ * --output-by-language; --output-by-filetype; --output-by-filename, or
+ --by-language; --by-filetype; --by-filename
+ * sisu_commands.ssi, manpage sisu.1, man2html
+ * [a8493b2] v3: css, ensure css available for generated content
+ * checks whether exists if not copies (for --init-site / --configure just
+ copies, takes as a re-copy request)
+ * [38e85cc] v3: hub, manifest re-run where related multilingual documents, fix
+ * BUG breaks mini table of contents (minitoc) manifest for multilingual
+ files,
+ better run without manifest minitoc, use --exc-manifest-minitoc
+ * [45a35b7] v3: sisupod.txz processing
+ * BUG image copying/processing for sisupod
+ * [fae668e] v3: hub, share markup source (--source) not available for
+ composite files
+ * suggest creating a sisupod instead
+ * [e8b29c3] v3: html_format, minor cleaning
+ * [ef7a5f3] debian/control program "tree" moved to Recommends from Suggests
+ * if available and verbose set, used to pre-view sisupod content during its
+ creation (--sisupod --verbose)
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 28 May 2012 05:45:27 -0400
+
+sisu (3.2.9-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [784eb3f] sha256 (3.2.8)
+ * [bd9d05b] v3: 3.2.9 version & changelog "opened"
+ * [b26ce9d] v3: harvest, fix some details
+ * harvest by filename output paths
+ * harvest_topics, add level
+ * harvest_topics, alternative headings, fix
+ * [8754d67] v3: options, create manifest touched
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 19 May 2012 23:27:58 -0400
+
+sisu (3.2.8-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [d13ffd5] sha256 (3.2.7)
+ * [0832d42] v3: 3.2.8 version & changelog "opened"
+ * [99965a5] v3: rescue & error warnings, more touched
+ * [5dace95] v3: reporting, composite file names touched
+ * [782e36f] v3: sst_identify_markup, document header SiSU 3.0
+ * pretty much as SiSU 2.0, some header additions
+ * identification not fully implemented
+ * [5fffe95] v3: a few misc fixes
+ * options, omissions and typo fix
+ * particulars, fix, check
+ * shared_metadata, fix
+ * [64c7305] v3: hub, fixes, still a construction zone
+ * [35825d2] v3: po4a, runs, needs checking
+ * [2dee3ab] v3: sisupod make, re-fixed, check again
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 12 May 2012 19:30:27 -0400
+
+sisu (3.2.7-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [67b15a4] sha256 (3.2.6)
+ * [d52bc28] v3: 3.2.7 version & changelog "opened"
+ * [5af7a5e] v3: rescue & error warnings, some touched
+ * [da82e36] v3: qrcode, fixes
+ * ensure manifest is run
+ * urls fix
+ * [6c38bed] v3: hub, options, fixes: dbi: pgsql, sqlite
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 06 May 2012 23:58:16 -0400
+
+sisu (3.2.6-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [93e1767] sha256 (3.2.5)
+ * [712054c] v3: 3.2.6 version & changelog "opened"
+ * [aae35fa] v3: harvest (metadata, site/document summary) fixes
+ * harvest_topics, sort fix
+ * harvest_authors, minor fix
+ * sst content parsing lang dir
+ * output file location, currently works for (by?) :language & :filetype
+ * [714a14f] v3: misc, minor
+ * [f297b90] v3: hub (seek finer grained control over what happens when;
+ causes breakage)
+ * (primarily) cycle files then options (instead of options then files)
+ * manifest re-run on (currently generated) translated files if any
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 01 May 2012 23:40:04 -0400
+
+sisu (3.2.5-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * [554b061] sha256 (3.2.4)
+ * [f95eb55] v3: 3.2.5 version & changelog "opened"
+ * [173a8be] v3: shared_html_lite, codeblock fix, affecting sql
+ * SELECT ocn,body FROM doc_objects WHERE t_is='code';
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 22 Apr 2012 13:52:47 -0400
+
+sisu (3.2.4-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [93f30fc] sha256 (3.2.3)
+ * [a8b8640] v3: 3.2.4 version & changelog "opened"
+ * [06520be] v3: db bugfix in maintenance mode (variable name reused)
+ * [5ae11e0] v3: sysenv, default processing dir name change
+ * distinguish sisu branch, add sisu branch to processing directory name
+ * if constants, 'DEVELOPER[:maintenance] == :true' then additionally add
+ sisu version number to processing directory name
+ * [d810b3f] v3: rescue reporting
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 21 Apr 2012 01:56:49 -0400
+
+sisu (3.2.3-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * [9de3fc4] sha256 (3.2.2)
+ * [0e9a8b0] v3: 3.2.3 version & changelog "opened"
+ * [0013ec9] v3: param, dal_syntax, document header (simple regex)
+ substitution list
+ * $ and curly braces are escaped (within sisu) to allow the following:
+ @make:\n :substitute: /${linux-distro}/,'Debian' /${stable}/,'Squeeze' \
+ /${testing}/,'Wheezy'
+ * changes are not made within text object types: code-blocks, tables or
+ metadata (document headers). Marked up document remains self-referential.
+ * Note: the substitution list must be written on a single line, without
+ line-breaks.
+ * [Substitutions possibility requested by Debian-live, live-manual (Ben
+ Armstrong & Daniel Baumann)]
+ * [8fefa22] v3: vim syntax highlighting, document header added (@make:)
+ :substitute:
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 15 Apr 2012 00:40:00 -0400
+
+sisu (3.2.2-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * [db578f6] sha256 (3.2.1)
+ * [b9d03b2] v3: 3.2.2 version & changelog "opened"
+ * [19c9608] v3: sysenv, path.style (a quick fix, review)
+ * [6a6c011] v3: urls, reporting, some cleaning
+ * [683ca12] v3: sql creation -v reporting reduced
+ * [717bc0a] debian/control: sisu-pdf, add texlive-math-extra for
+ realscripts.sty
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 05 Apr 2012 14:56:17 -0400
+
+sisu (3.2.1-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [9b91ce6] sha256 (3.2.0)
+ * [d8beb2f] v3: 3.2.1 version & changelog "opened"
+ * [a5873a4] COPYRIGHT add markup samples "Free as in Freedom"
+ * [582f1bb] v3: documentation sisu_commands, manpage, html (man2html)
+ * [c3393c9] debian/copyright, add markup samples "Free as in Freedom"
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 21 Mar 2012 20:01:17 -0400
+
+sisu (3.2.0-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [553f6ba] sha256 (3.1.15)
+ * [356854c] sha256 (3.1.15-2)
+ * [349975b] v3: 3.2.0 version & changelog "opened"
+ * [6811ac9] v3: 3.2 branch is main (v3dv --> v3); dev (v3dv) branch
+ directories removed
+ * v3dv (3.2) "merged" into v3 (previously 3.1) (& removed)
+ * conf/sisu/v3dv --> conf/sisu/v3
+ * data/sisu/v3dv --> data/sisu/v3
+ * lib/sisu/v3dv --> lib/sisu/v3
+ * bin/sisu* (v3dv references changed to v3)
+ * (--dev modifier (superfluous for the time being) runs main v3 branch)
+ * [6528dc8] COPYRIGHT, name change using uppercase, format changed
+ * content format influenced by Machine-readable debian/copyright file
+ <http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/>
+ * [8eaab90] debian/bin/sisu* (change v3dv references to v3)
+ * [488d0b7] debian/sisu.lintian-overrides remove v3dv
+ * [563106f] debian/sisu.install vim related installs, use v3 (rather than v2)
+ * [84644d4] debian/copyright format changed
+ * content format influenced by Machine-readable debian/copyright file
+ <http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/>
+ * [32979c6] debian/control debhelper Standards Version: 3.9.3
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 19 Mar 2012 22:30:12 -0400
+
+sisu (3.1.15-2) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * [7fd1f26] debian/bin/sisu* enable (commands on) --dev (v3dv branch)
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 13 Mar 2012 22:03:32 -0400
+
+sisu (3.1.15-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * [8f91f70] sha256 (3.1.14)
+ * [dc4c672] v3 v3dv: 3.1.15 & 3.2.0~pre version & changelog "opened"
+ * [2e1d003] v3dv: lib, clean trailing whitespace
+ * [231c64e] v3dv: texinfo, fix (break holding back 3.2 merge)
+ * proposed next version starts 3.2, (merge dev branch after 3.1.15)
+ * [4cdfa55] v3dv: sysenv, param, options, output control hooks code modified
+ * for config file, document headers, & command line
+ * requiring downstream code changes (in commit that follows)
+ * [756caa5] v3dv: start using output control hooks
+ * for config file, document headers, & command line
+ * v3dv: sysenv, ProcessingSettings, start to use hooks to make it possible
+ to control (via: the command line; the document markup header, or; the
+ configuration file) the likes of: ocn, toc, segsubtoc, minitoc,
+ links-to-manifest, search-form, html-navigation, html-navigation-bar,
+ html-right-pane, html-top-band; these are switched on by default and may
+ be switched off in omit lists within configuration file, the document
+ markup header, or command line. The command line takes precedence & may
+ switch on or off overriding settings within the document markup header or
+ the sisu configuration file.
+ * --inc- on by default, but if switched off in doc header or
+ configuration, the command line --inc- has precedence; for each possible
+ exclude configuration the --inc- switch that overrides configuration
+ settings
+ * --exc- == --no-; exclude/switch off feature (but --inc- include has
+ precedence)
+ * document header @build: :omit: [list output features to be omitted]
+ * configuration (sisurc.yml) omit:
+ exclude output feature, overrides configuration settings (omit --dev
+ development branch modifier once merged back to main)
+ --exc-ocn, html (seg, scroll), epub, xml, pdf
+ sisu --dev --exc-ocn --html --epub --xml-sax --xml-dom --xhtml -v \
+ filename.sst
+ --exc-toc, html (scroll), epub, pdf
+ sisu --dev --exc-toc --html --epub --pdf -v filename.sst
+ --exc-segsubtoc html (seg), epub
+ sisu --dev --exc-segsubtoc --html --epub -v filename.sst
+ --exc-minitoc, html (seg), concordance, manifest
+ sisu --dev --exc-minitoc --html --concordance -v filename.sst
+ --exc-manifest-minitoc, manifest
+ sisu --dev --exc-manifest-minitoc --html -v filename.sst
+ --exc-links_to_manifest, --exc-manifest-links,
+ html (seg, scroll)
+ sisu --dev --exc-manifest-links --html -v filename.sst
+ --exc-search-form, html (seg, scroll), manifest
+ sisu --dev --exc-search-form --html -v filename.sst
+ --exc-html-minitoc, html (seg), concordance
+ sisu --dev --exc-html-minitoc --html --concordance -v filename.sst
+ --exc-html-navigation, html (seg, scroll)?
+ sisu --dev --exc-html-navigation --html -v filename.sst
+ --exc-html-navigation-bar, html (seg)
+ sisu --dev --exc-html-navigation-bar --html -v filename.sst
+ --exc-html-search-form, html (seg, scroll)
+ sisu --dev --exc-html-search-form --html -v filename.sst
+ --exc-html-right-pane, html (seg, scroll)
+ sisu --dev --exc-html-right-pane --html -v filename.sst
+ --exc-html-top-band, html (seg, scroll), concordance (minitoc is
+ forced on to provide seg navigation)
+ sisu --dev --exc-html-top-band --html --concordance -v filename.sst
+ * [c79ce1e] v3dv: vim syntax highlighting, document header added :omit: (under
+ @make)
+ * [b53d63a] v3dv: documentation sisu_commands, rearranged & update with regard
+ to excludes
+ * sisurc.yml omit list, commented out omit line with single example added
+ * [86b767b] v3dv: sqlite3 discreet .sql.db file for each document (possibility
+ added)
+ * in addition to existing possibility of a shared db in sqlite3 or
+ postgresql
+ * [58bc2e5] v3dv: documentation sisu_commands, add sqlite3 discreet
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 12 Mar 2012 18:55:10 -0400
+
+sisu (3.1.14-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [87f1037] sha256 (3.1.13)
+ * [7fbe341] v2 v3 v3dv: 3.1.14 & 3.2.0~pre (& 2.9.12) version & changelog
+ "opened"
+ * [525b4f1] v2: vim syntax highlighting, patch from Thilo Six
+ <T.Six@gmx.de> applied
+ * Re: <http://thread.gmane.org/gmane.editors.vim.devel/32151> &
+ <http://vimdoc.sourceforge.net/htmldoc/options.html#cpo-l>
+ [for v3, see sisu_3.1.13 changelog]
+ * [8138e23] v3dv: sysenv, output_dir_structure, rewritten, affected code
+ modified
+ * [2b884fb] v3dv: --redirect (--redirect=dir_path) & --dump (--dump=dir_path)
+ + consequences
+ * --dump places output in directory specified, if none specified in the
+ current directory (pwd).
+ * --redirect places output in subdirectory under specified directory,
+ subdirectory uses the filename (without the suffix). If no output
+ directory is specified places the subdirectory under the current directory
+ (pwd).
+ * html, css incorporated into each file (concordance & manifest included)
+ * html, xhtml & xmls, css copied into css subdirectory (not used by html as
+ embedded)
+ * html xmls, images copied to output directory
+ * no links to manifest
+ * manifest with relative links only
+ * longer html filenames given to avoid names clashing (e.g. for toc,
+ manifest, concordance)
+ * html, epub, remove manifest toc links
+ * -j copy images associated with file (images used by html & xmls)
+ * automatically invoked by --dump & redirect
+ * v3 v3dv: document --redirect, --dump, -j update sisu_commands.sst
+ [documents not generated until v3.2.0 (when v3dv branch is merged into
+ v3)]
+ * [f653df1] v3dv: dal, remove sisu_manifest from document structure & toc
+ * html & epub coding affected
+ * [6d898f1] v3dv: control hooks
+ * hooks to make it possible to control (via: the command line; the document
+ markup header, or; the command line) the likes of: toc, manifest,
+ manifest-links, metadata, html-minitoc, html-navigation,
+ html-navigation-bar; these are switched on by default and control takes
+ the form of making it possible to switch them off.
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 14 Feb 2012 21:45:12 -0500
+
+sisu (3.1.13-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [527f905] sha256 (3.1.12)
+ * [071c6db] v3 v3dv: 3.1.13 & 3.2.0~pre version & changelog "opened"
+ * [6dd8de8] v3 v3dv: vim syntax highlighting, patch from Thilo Six
+ <T.Six@gmx.de> applied
+ * Re: <http://thread.gmane.org/gmane.editors.vim.devel/32151> &
+ <http://vimdoc.sourceforge.net/htmldoc/options.html#cpo-l>
+ * [145f309] v3 v3dv: path & url links, updates for multiple output directory
+ structures
+ * [7e3cee5] v3dv, dal +, use symbols to identify document objects type (is)
+ and group (of)
+ * (dal & code affected as a result)
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 03 Feb 2012 20:46:07 -0500
+
+sisu (3.1.12-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [aa8f0ce] sha256 (3.1.11)
+ * [89bbbb5] v3 v3dv: 3.1.12 & 3.2.0~pre version & changelog "opened"
+ * [0b38bae] v3 v3dv: urls, odt maintenance path fix
+ * [7e9a59c] v3 v3dv: texpdf, tampering with "safe" special character
+ transformations, a fix
+ * could introduce new issues, watch
+ * [reported by Timothy Hume, pdf title bug "&" not represented]
+ * [45a3eb9] v3dv: sysenv, use "which" instead of "whereis" to locate programs,
+ test
+ * [suggested by, Timothy Hume, used to get sisu texpdf to work on MacOS]
+ * [3d6deb1] v3dv: call most methods by full name (include associated module &
+ class names)
+ * messing with code, merge back now likely to become v3.2
+ * [21f5e22] v3dv: replace use of most ruby exclamation (!) method actions
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 23 Jan 2012 21:53:09 -0500
+
+sisu (3.1.11-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [c977c09] sha256 (3.1.10)
+ * [aef3a25] v2 v3: 3.1.11 version & changelog "opened"
+ * [9d687db] v2: modify, sisu markup version script (take from v3)
+ * [a0c2826] v3: modify.rb, prep script for year update, & changing module &
+ class names
+ * [1677a58] v3: date, year 2012, update
+ * [75e3bf8] v3dv, add dev branch (use to make some changes to module & class
+ names & test)
+ * (intended as) short term branch, merge back into v3 once tested
+ * sisu --dev (to invoke)
+ * [51ba2d7] v3dv: module names, use more CamelCase
+ * [732dca2] v3dv: class names, remove "SiSU_" (reserve for module names for
+ consistency)
+ * [df67ee1] v3dv: class names, use more CamelCase
+ * [19e69de] v3dv: make further changes to module names & test
+ * [16db2c6] v3dv: SiSU_DAL_ for module names in dal, & module Metadata is
+ SiSU_Metadata
+ * v3dv: modify.rb script (& its artifact) removed (after use) from lib/sisu
+ modify.rb script remains available (in generic form) under:
+ data/sisu/v3/conf/convert/modify.rb
+ data/sisu/v3dv/conf/convert/modify.rb
+ * [c2d14cc] debian/sisu.lintian-overrides, repeat for v3dv
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 10 Jan 2012 23:22:59 -0500
+
+sisu (3.1.10-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [5712c0b] sha256 (3.1.9)
+ * [7c9212e] v3: 3.1.10 version & changelog "opened"
+ * [66d8155] v3: html, epub, (& xml) codeblocks, treatment of '<<' & '>>', fix
+ * (remove legacy codeblock match rule, watch)
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 31 Dec 2011 08:39:12 -0500
+
+sisu (3.1.9-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * [cfaad12] sha256 (3.1.8)
+ * [a39fede] v3: 3.1.9 version & changelog "opened"
+ * [598c4fe] v3: options, --find & --glob, use for general search in base
+ directory
+ * cannot be limited by sub-directory, error message provided
+ * [9ef4a60] v3: sysenv, html files in _sisu/home (*.html) copied as home pages
+ * [d71c116] v3: html, seg output, index.html fixes
+ * place in correct directory and use language code as appropriate
+ * remove broken index.html from output [note the existing erroneous file is
+ not removed by a program run, it has to be removed manually]
+ * [issue reported by chals (debian live-manual) on irc oftc #sisu]
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 19 Dec 2011 22:55:13 -0500
+
+sisu (3.1.8-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * [a6aadc4] sha256 (3.1.7)
+ * [59a52e3] v3: 3.1.8 version & changelog "opened"
+ * [0607a1b] v3: odf:odt, codeblocks, a match fix, affects e.g. "<<"
+ * [b77338f] v3: texpdf, output_by: filetype, fix, language code part of
+ filename, fix
+ * files previously given same name and written over
+ * [reported by chals (live-manual) on irc oftc #sisu]
+ * [output_by language and filename ok]
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 13 Dec 2011 22:11:38 -0500
+
+sisu (3.1.7-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [5989174] sha256 (3.1.6)
+ * [858fc0b] v3: 3.1.7 version & changelog "opened"
+ * [9cdd523] v3: dal, codeblocks, removed identifier tags, changed markup of
+ "<" & ">"
+ * [9ea7b7f] v3: epub, css, codeblock, grey box
+ * [595970f] v3: texpdf, codeblocks, use listings package (for grey box)
+ * (internally retain possibility to use boites package)
+ * [4c67b33] v3: sysenv, only copy external images directory if it exists
+ * [cda92b5] v3: documentation, add --configure, use ascii chars for dir tree,
+ correct typos
+ * [0260753] v3: documentation, manpage & html (man2html)
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 08 Dec 2011 21:32:49 -0500
+
+sisu (3.1.6-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [a4295e2] sha256 (3.1.5)
+ * [fc90866] v3: 3.1.6 version & changelog "opened"
+ * [83f669a] v3, require iconv (removed), should use String#encode instead,
+ watch
+ * removed iconv, required a number of places without being used, watch
+ * [acd2e81] v3: dal, codeblocks, start flush left (no buffer spaces at start
+ of line)
+ * allows cut & paste of codeblocks (from some output formats)
+ [requested by chals irc.oftc]
+ * [d513733] v3: texpdf, use boites for box round codeblocks
+ * use and adapt 'boitecoloriee' (found in boites_examples.sty)
+ * in boitebox as setup normal tex hardspaces at start of line are removed,
+ hack required to fix
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 02 Dec 2011 04:08:40 -0500
+
+sisu (3.1.5-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [4a239cf] sha256 (3.1.4)
+ * [b80f7be] v3: 3.1.5 version & changelog "opened"
+ * [b5c036a] v3: dal_expand_insertions, link shortcut for sisu documents,
+ omit codeblocks
+ * [ecd91fe] v3: sisu manual, sisu markup, e.g. of link shortcut for multiple
+ sisu documents
+ * [b19886a] v3: param, sisupod_make, sisu markup embedded symbol images regex,
+ case added
+ * [2d9e5ec] v3: odf:odt v1.2
+ * includes previously unimplemented hanging indents
+ * done: dal, plaintext, html, epub, xhtml, xml (sax & dom), odt, pdf, sql;
+ not done: man, info
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 21 Nov 2011 00:16:22 -0500
+
+sisu (3.1.4-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [ed249df] sha256 (3.1.3)
+ * [d480a1d] v3: 3.1.4 version & changelog "opened"
+ * [d17e724] v3: FileUtils, make explicit calls (more verbose, easier to find)
+ * [b59529b] v3: FileUtils, replace system calls
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 11 Nov 2011 00:10:12 -0500
+
+sisu (3.1.3-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [daa1082] sha256 (3.1.2)
+ * [6404e3e] v3: 3.1.3 version & changelog "opened"
+ * [f301599] v3: fix necessary, Re: (3.1.2) [da4acc7] header, bold & italic
+ pattern matching
+ * header, bold & italic pattern matching, ignore case (possibility
+ reinstated) @make: :bold: :italic: /[regex]/i
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 05 Nov 2011 19:48:05 -0400
+
+sisu (3.1.2-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [97df42b] sha256 (3.1.1)
+ * [9c52c3c] v3: 3.1.2 version & changelog "opened"
+ * [12ffabd] v3: markup-samples, Free as in Freedom 2.0
+ * [c148cfd] v3: markup-samples, Free as in Freedom 2.0, made use of old book
+ index
+ * (made use of old book index) better than none
+ * [3ba9db6] v3: concordance, information to terminal, minor
+ * [df67ba2] v3: conf/convert/modify.rb minor fixes
+ * [87608df] v3: sysenv, skins, a fix
+ * [da4acc7] v3: header, bold & italic pattern matching, ignore case
+ (possibility reinstated)
+ * (bold & italic pattern matching) @make: :bold: :italic: /[regex]/i
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 31 Oct 2011 22:08:02 -0400
+
+sisu (3.1.1-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [0dad10b] sha256 (3.1.0)
+ * [a29324f] v2 v3: 3.1.1 version & changelog "opened"
+ * [fadbc35] v3: manifest, odt url lnk, fix
+ * [6d46257] v2 v3: odf:odt v1.0: make odt header easier to track; remove
+ binary blob
+ * make odt header changes easier to track
+ (this commit maintains rough equivalence to sisu-3.1.0 headers)
+ * sysenv, builds odf:odt directory structure instead of binary blob
+ * get rid of odf:odt (binary changeset) blob zipfile (containing odf:odt
+ directory structure)
+ * [aa06692] v3: odf:odt, make odt style names more easily recognizable
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 15 Oct 2011 14:01:14 -0400
+
+sisu (3.1.0-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [0254006] sha256 (3.0.19)
+ * [e8daf99] v2 v3: 3.1.0 version & changelog "opened"
+ * [366895d] v2 v3: bin/sisu, default sisu version 3
+ * Version 3 is now the default (on running sisu)
+ * [a8472db] v3: sysenv, rc_path adds ./.sisu/
+ (to existing ./_sisu/ & ~/.sisu/)
+ * [8925b88] v3: defaults, (sisu) home page, link to git repo, minor fixes
+ * [7fb6acc] v3: texpdf, fonts, Liberation series default
+ (main: Sans, mono: Mono)
+ * (mono) improved with selection of Liberation Mono as default
+ * font (main font, mono) configurable in sisurc.yml under
+ default: (texpdf_font:|texpdf_font_mono:)
+ or within document under @make: (:texpdf_font:|:texpdf_font_mono:)
+ * [53e6d1a] v3: sisrc.yml, texpdf_font (main, mono) Liberation series
+ (main default Sans)
+ * [c6f5cd1] v3: vim syntax, :texpdf_font_mono: added to @make:; proposed
+ header changes
+ * sisu_next.vim, track proposed syntax (header) changes
+ * [2547d72] v3: sysenv, output_structure_by: filename, fix to output
+ directories created
+ * [7997984] v2 v3: documentation, small update
+ * [e9c80fc] v2 v3: documentation, manpage
+ * [5e53466] v2 v3: documentation, html, minor (removal of trailing
+ whitespaces)
+ * [85bd723] v2 v3: documenation, html, man2html (sisu.1)
+ * [9660639] debian/bin/sisu, default sisu version 3
+ * [d1b4eb4] debian/sisu.manpages, manpage for sisu2
+ * [f28109e] debian/sisu.NEWS.Debian sisu v3 is default
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 03 Oct 2011 21:27:42 -0400
+
+sisu (3.0.19-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * [5ade3b6] sha256 (3.0.18)
+ * [035c656] v2 v3: 3.0.19 version & changelog "opened"
+ * [1846773] v2: remote, image source url fix
+ * [8edbb13] v2 v3: param, matching of date, years 1400 - 21\d\d
+ * [5048519] v3: cosmetic, minor
+ * [794c20f] v3: hub, processing options, remove cruft
+ * [344270f] v3: info files, fix output; remote, include info file & manpage
+ (when selected)
+ * [b1d08ce] v3: qrcode, sisu generated manifest output, treat as such
+ * place qrcode images in directory under manifest (manifest/qrcode)
+ * fix remote placement of qrcode images when requested
+ * [0081730] v3: remote, src & sisupod processing, and rsync placement
+ * [9d759c2] debian/bin/* update checks, sisu2 added
+ * [9b5edd8] debian/sisu.install: install sisu2 added; no longer install for
+ ruby 1.8
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 24 Sep 2011 09:07:35 -0400
+
+sisu (3.0.18-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [0d5cc01] sha256 (3.0.17)
+ * [0fdc7c9] v3: 3.0.18 version & changelog "opened"
+ * [ab8d19c] v3: CHANGELOG_v3, correct .orig.tar.xz name (>=3.0.15)
+ * [2ec7a07] v3: correct sisupod references and path to .txz (replace .zip)
+ * [65e4c06] v3: options, match fix for --glob / --find
+ * [af7543c] v3: options, (hub), action (opt.act) modified to increase use
+ possibilities
+ * [705ccf7] v3: hub (affecting options +others) sisupod processing
+ (v2 enabled)
+ * [403a52d] v3: dal_images, disabled imagemagick configuration permission
+ check
+ * until sisupod reads local sisurc.yml (configuration file)
+ * [c2163c5] v3: image (relative) paths for different sisu output structures
+ * (re: by_language, by_filetype, by_filename)
+ * sysenv, set path
+ * html seg, scroll, manifest (qrcodes), xmls
+ * [e70f634] v3: epub
+ * fix for different output structures, language codes not used
+ internally (within epub)
+ * adjustment to image paths for image copy
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 13 Sep 2011 19:30:08 -0400
+
+sisu (3.0.17-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [0bf06f6] sha256 (3.0.16)
+ * [a035400] v3: 3.0.17 version & changelog "opened"
+ * [7bc559f] v3: unix conditional tests (? :) remove line break markers before
+ : cosmetic
+ * [b5712bc] v3: Dir.chdir, remove "system cd" (change directory) use
+ Dir.chdir
+ * [22f6ac0] v3: sisupod_v3 make (build); place (rsync); process (generate
+ sisu output from)
+ * sisupod v3
+ * modify pod dir structure, place sisu source in dir/[lang_code]/
+ e.g. dir/en/
+ * use tar.xz (.txz)
+ * bundle all language version in pod
+ * bundle .ssm and all included files for each selected language (rather
+ than composited .ssm.sst file)
+ (filename pattern) or named in files to be processed string
+ * remote placement
+ * sisu processing from sisupod v3
+ * rsync sisupod v3
+ * sysenv, check that tree is available and use as desired when available
+ * [a19f7c8] debian/control +Suggests: tree (for option to show file structure)
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 05 Sep 2011 11:20:24 -0400
+
+sisu (3.0.16-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [9c24ffc] sha256 (3.0.15)
+ * [5041a3d] v3: 3.0.16 version & changelog "opened"
+ * [3ff0378] v3: html_format, texinfo_format, minor, html seg presentation fix
+ * [084e7d2] v3: sysenv, cosmetic, code arrangement touch
+ * [90ad666] v3: epub, param, (defaults) epub tuning
+ * include levels A - C as individual sections
+ (xhtml file with consistent opf & ncx)
+ * sync ncx with sisu internal structural logic
+ (correct depth, include level A, place sisu toc)
+ * [6bd77e1] v3: concordance, i18n, start adding alternative language alphabets
+ * Danish, Norwegian, Swedish
+ * [cacb056] v3: dal, sisu document links (multiple output versions) shortcut
+ * links to multiple versions internal documents based on shortcut notation,
+ e.g.
+ { "Viral Spiral", David Bollier [3sS]}viral_spiral.david_bollier.sst
+ resulting in all versions of the document that would be generated by
+ running the command sisu3 -3sS viral_spiral.david_bollier.sst
+ * added possibility to specify language where language directory structure
+ is used for source documents
+ { "Viral Spiral", David Bollier [3sS]}en/viral_spiral.david_bollier.sst
+ * [4d066c1] debian/watch watchfile for .tar.xz (instead of .tar.gz)
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 18 Aug 2011 23:25:44 -0400
+
+sisu (3.0.15-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [439b8be] sha256 (3.0.14)
+ * [07065d9] v3: 3.0.15 version & changelog "opened"
+ * [f0da30b] v2 v3: removed objects.txt, cleaning
+ * [bd2ba36] v3: options, default action on running "sisu3 [filename.sst]", fix
+ * [eb47453] v3: options, sysenv, sisurc.yml, set/config default language
+ (code)
+ * in absence of setting 'en' assumed
+ * 'en' previously fixed
+ * [c610cd6] v3: po4a, make use of base directory (default) language setting
+ * set original language, (instead of assuming English)
+ (per directory or wider)
+ * [a588b8f] v3: prog_text_translation, add contents, remove some repetition
+ * [7c0a734] v3: texpdf, possibility to translate "Contents" for table of
+ contents
+ * [04d3390] v3: constants, re-arranged
+ * [532c030] v3: epub, constants, experiment with presentation
+ * disable some internal "features"
+ * make file and directory naming more flexible, now using
+ 'OEBPS', 'toc.ncx', 'content.opf',
+ * adjustment of some headers and general tuning
+ * add opf guide
+ * clean processing directory between each build
+ * constants, added constants Ep (for epub)
+ * constants, added DISABLE (used here with epub)
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 09 Aug 2011 20:25:53 -0400
+
+sisu (3.0.14-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [45a05d0] sha256 (3.0.13)
+ * [9056c5a] v3: 3.0.14 version & changelog "opened"
+ * [2008439] v3: urls, --concordance (hyphen added, descriptive)
+ * [b739f3f] v3: sysenv, avoid creation of spurious directories in output tree
+ * an image copy section removed (re-implement correctly later)
+ * [9c518b4] v3: sysenv, cosmetic
+ * [5eb77a9] v3: param, cleanup setting of auto endotes
+ * [bdc8fb1] v3: xmls (sax, dom, xhtml) use of tidy, correct output location
+ * [427c8b2] v3: texpdf, XeTeX language settings
+ (setmainlanguage setotherlanguage)
+ * get from directory or filename if header @make: :language: not set
+ * [a44bbf2] v3: epub, opf fixes
+ * [f965e59] v3: qrcode, manifest, (++), QR code (metadata) images for manifest
+ * generate images using qrencode
+ * [2e6af20] v3: param, manifest, qrcode, epub, added creator.editor field
+ * [399e6ea] v3: sql db, constants, cgi-sql, structure changed, creator.editor
+ field added
+ * [c77953f] v3: vim sisu syntax highlighting
+ * markers for hanging indent added
+ * added header for @creator: :editor:
+ * minor comments added
+ * deletion of an unused tag
+ * [afa7647] v3: emacs syntax highlighting sisu-mode.el
+ * markers for hanging indent added
+ * line-break
+ * [5e29210] v3: dal, indent, control of first line of indent & rest of
+ paragraph
+ * implements hanging indent, and possibility to set first line step indent
+ * __[1-9] hanging indent (initial indent 0); paragraph text indent [1-9]
+ * _[0-9]?_[1-9] initial indent; paragraph text indent
+ * __[1-9]! bold words \\ part of hanging indent paragraph text
+ * [051b321] v3: plaintext, indent ...
+ * [476ee85] v3: css, indent ...
+ * [1abd2f9] v3: xhtml, xml sax & dom, indent (partially implemented) ...
+ * [392f8d5] v3: html, indent ...
+ * [727db14] v3: epub, indent ...
+ * [dba6d8b] v3: texpdf, indent ...
+ * [e3330f1] v3: sql (pg, sqlite), indent ...
+ * [d9dcd89] v3: odf, manpage, "new" indent not implemented
+ * [d613c97] v3: po4a, indent (check for breakage)
+ * [bd65e8a] v2 v3: sisu_manual
+ * sisu_commands: --qrcode -Q; update shortcut options; line-breaks use \\
+ * sisu_markup.sst: indent update; publisher
+ * [520128d] v2 v3: manpage
+ * commands: --qrcode -Q; update shortcut options
+ * markup.sst: indent update; publisher
+ * [3c0b56d] v2 v3: manpage html (man2html)
+ * commands: --qrcode -Q; update shortcut options
+ * markup.sst: indent update; publisher
+ * [b616560] debian/control sisu recommends qrencode
+ * used in sisu v3 to place metadata images in manifest
+ * [a027696] debian/sisu.install sisu v3 ruby libraries only in 1.9.1 (not 1.8)
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 26 Jul 2011 21:00:18 -0400
+
+sisu (3.0.13-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [cd0c1c8] sha256 (3.0.12)
+ * [3ef6432] v2 v3: 2.9.7 & 3.0.13 version & changelog "opened"
+ * [533909b] v2 v3: vim colors, added cursor line & cursor column
+ * [8335580] v2 v3: dal_syntax, linebreak in regular text object: ' \\ '
+ ('<br>' depreciated)
+ * thanks to Jonas Stein for making me look at this
+ (see bug: #617298 & comments in upstream CHANGELOG_v3)
+ * testing required, downstream outputs affected
+ * [8294a1d] v2 v3: vim, sisu syntax highlighting, linebreak \\ added
+ (<br> kept)
+ * [60bd031] v3: ansi screen reporting include document language code
+ * [7ef0302] v2 v3: texpdf, define hardspace & provide backslash
+ * define \hardspace to simplify placing a hardspace
+ * provide backslash character in code block
+ * [d95f857] v3: define latex \newcommands for some special characters
+ (for sisu code)
+ * \newcommands for some special characters to simplify dealing with them
+ in sisu code \hardspace \caret \pipe \curlyopen \curlyclose \lt \gt
+ \slash \backslash \underscore \exclaim
+ * [3dafcae] v3: constants, a sisupod & an xml related addition
+ * [561b3d6] v3: plaintext, codeblock keep backslashes
+ * [b975bd0] v3: html_tune, reduce loops; deal with angle-brackets
+ * deal with angle brackets in markup (test, could cause breakage)
+ * reduce loops in code
+ * [def544b] v3: manpage (sysenv), move output; line-breaks within object
+ * start to honor line-breaks within objects (revisit)
+ * show double escape \\ (backslashes) in code blocks
+ * place under web server directory
+ * sysenv, accommodate manpage changes
+ * [408bf6b] v3: info (texinfo) (sysenv), move output; line-breaks within
+ object
+ * backslashes & line-breaks
+ * place under web server directory
+ * info tool setting prompt
+ * sysenv, accommodate info page changes
+ * [f6f89c9] v3: sysenv, fix some output paths (markup source); accommodate
+ manpage
+ * shared source markup (.sst .ssm & sisupod.zip) fix some paths
+ * placement of markup source, output_path.src.dir, fix
+ * output_path.src.url, fix
+ * manifest info
+ * (epub viewer cosmetic rearrangement)
+ * [b232545] v3: manifest, manifest enable additional output & source
+ (if shared)
+ * manpage (in fututure have config setting with default false/off)
+ * info (texinfo) (in fututure have config setting with default false/off)
+ * hash digests
+ * locate markup source (if shared)
+ * sisupod (if shared)
+ * [ae914fd] v3: urls (ansi screen reporting), add document language code
+ * [c552333] v2 v3: sisurc.yml, config settings
+ * [1d239f2] v3: documentation, on additional breaks in document,
+ (remove some old info)
+ * linebreak \\ (previously undocumented <br> kept but depreciated)
+ [it is intended that this should close #617298 (post mail)]
+ * page break (breaks column if column, else breaks page)
+ * page new (new page, breaks page)
+ * sisurc.yml set output directory structure by language
+ * removed section on hyperestraier, too specialised for general manpage
+ (also section not checked recently)
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 26 Jun 2011 22:42:28 -0400
+
+sisu (3.0.12-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * [21117c4] sha256 (3.0.11)
+ * [93d6609] v2 v3: 2.9.6 & 3.0.12 version & changelog "opened"
+ * [5f4c703] v2 v3: help, s/Bul garian/Bulgarian/ (Closes: #619068)
+ * [7bf74c7] v3: options, restrict glob rule checks to glob & find; carry lang
+ info
+ * restrict glob rule checks to when --glob (-G) or --find (-f) requested
+ * carry information on document language (from filename and or directory)
+ * (additional test)
+ * [6a7c87d] v3: --help language, provides list of available languages
+ * language (ISO 639-1 code (as varied by po4a) & name)
+ * [36c4c6a] v3: manifest, fix a full name
+ * [a011db3] v3: html, texpdf, syslink to default, adjusted & made similar
+ * [2aba456] v3: param, remove unused class variable '@@symlnk'
+ * [d0fd14a] v3: sysenv, limit/prevent the creation of spurious language output
+ directories
+ * [a6651ef] v3: harvest, work for alt output structures; for each language
+ * paths to document manifests etc. for the possible output dir structures
+ * author and topic lists for available documents, by availability in each
+ language
+ * [74c346f] v3: cgi, sample search form reverted to '#!/usr/bin/env ruby'
+ * appears to be a fix in libdbi-ruby1.9.1, see comments in sisu-3.0.8
+ changelog
+ * [5a1e3ba] v3: cgi, sample search form, force utf-8 character encoding to
+ avoid issues
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 09 Jun 2011 23:16:23 -0400
+
+sisu (3.0.11-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * [f4bb6f7] sha256 (3.0.10)
+ * [5794055] v3: 3.0.11 version & changelog "opened"
+ * [0df2126] v3: sysenv, url webserver link (manifest) fix
+ * [4d50928] v3: cgi search form, fixes related to language code
+ * filename with language code being required as unique document
+ identifier
+ * [b1648ad] v3: i18n, constants, some language info moved to i18n
+ (from constants)
+ * [93cc261] v3: options --find & --glob (-f -G) added, parses language
+ sub-dirs
+ * options
+ * filter out files not matching .ss[tm]
+ * with -f -G (--find|--glob) flag glob all .ss[tm] files in dir
+ including language sub-directories
+ sisu3 -3G live-manual
+ * with -f (--find|--glob) flag and find .ss[tm] files that match given
+ string in dir including language subdirectories
+ sisu3 -3GR
+ * [0e921ad] v3: documentation, minor update, includes --find / --glob
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 29 May 2011 20:49:17 -0400
+
+sisu (3.0.10-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * [e42cb23] sha256 (3.0.9)
+ * [3ce63d5] v2 v3: 2.9.5 & 3.0.10 version & changelog "opened"; copyright
+ touch
+ * copyright, dates for setup.rb
+ * [f7bad42] v3: sysenv, rsync, get rid of annoying nag to terminal
+ (-v reporting Dir.pwd)
+ * prevent attempt to change directory unless different directory requested
+ * [c11ed8c] v3: i18n, added language translation table column to hash/table
+ * changelog, version dates touched as well
+ * [92fb4ac] v3: prog_text_translation, language class name fix; languge name
+ matching
+ * Portuguese language class name (missed 't')
+ * language name matching ('Portuguese Brazil')
+ * indentation
+ * [a11485b] v3: param, html, epub, xml, simplify file-naming with language
+ code
+ * language code occurs in fixed location within file-name (could previously
+ do so in 1 of 3 configured locations)
+ * [eebc0d4] v3: manifest, sysenv, "available outputs" relative paths;
+ available languages
+ * relative paths to "available outputs" (for each dir structure), fix
+ * show language versions published
+ (needs 2 runs for manifest, polls output as to whether manifest exists)
+ * [b5b64d1] v3: texpdf, filenames
+ * [154fd68] v3: html, close files; syslink index.html to toc.html
+ * syslink will need revisit (will only "work" properly with by_language dir
+ structure)
+ * [3a07ef3] v3: options, include markup source "base" path
+ * used to parse alternative markup source dir structures
+ * [d6f18ae] v3: sysenv, rsync, embedded: rsync to remote host alt output
+ structures, fix
+ * [f18dfa7] v3: defaults, fix path to homepage image (more fixes remain...)
+ * [1ccbc25] debian/copyright, sync with package
+ * url update, date touched
+ * sisu-mode.el assignment to FSF (GNU EMACS)
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 23 May 2011 22:52:20 -0400
+
+sisu (3.0.9-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [015d5f0] sha256 (3.0.8)
+ * [6148816] v2 v3: 2.9.4 & 3.0.9 version & changelog "opened"
+ * [91ada8a] v2 v3: copyright file, softlink, make more visible in tarball
+ * [dbd7dce] v2 v3: copyright file update, sisu-mode.el assigned to FSF
+ (GNU EMACS)
+ * [5a3b602] v2 v3: bin/sisu2 introduced (complement bin/sisu3), currently
+ same as bin/sisu
+ * later switch bin/sisu to bin/sisu3
+ * consider using update-alternatives
+ * [62a6bc0] v2 v3: vim cterm colorschemes, touch search color
+ * [29fcf4a] v3: sysenv, output directory structure check, fix (start testing
+ alternatives)
+ * [cfa267b] v3: sysenv, options, output_dir_structure.by?
+ (language|filetype|filename)
+ * [b1b2fe8] v3: sysenv, output_path & place_file, modified
+ (affects many libraries)
+ * paths for dir, url, relative and rcp that vary with output dir structure
+ * cope with alterative dir structures
+ * manifest url paths, fix
+ * dal_expand_insertions, fix
+ * rsync, review
+ * scp disabled
+ * [a09e2e6] v3: cgi sample search form, differ depending on output directory
+ structure
+ * [ea971b8] v3: version & changelog date
+ * [f464a77] v3: embedded, source path
+ * [d87f4ff] v3: options, expand name of source file for selected language
+ directories
+ * only use for single file(name) available in multiple languages e.g.
+ sisu3 -hv en/free_culture.lawrence_lessig.sst es fr
+ * english assumed as default language, make default configurable later
+ * particularly useful for po4a
+ * [bdd62ab] v3: po4a re-enabled, related fixes (issues persist)
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 17 May 2011 18:12:54 -0400
+
+sisu (3.0.8-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [e1e81c7] sha256 (3.0.7)
+ * [89e5a25] v2 v3: 2.9.3 & 3.0.8 version & changelogs "opened"
+ * [5102422] v2 v3: bin/ improved ruby version check
+ * [624f72b] v2 v3: sysenv, refer to lowriter, update
+ * v2 lowriter instead of oowriter
+ * v3 lowriter instead of libreoffice
+ * [1e84a4d] v2 v3: vim, sisu syntax change of a couple of color groups
+ * [e208972] v2 v3: vim (8 color cterm) colorschemes, 8, frugal, sparse
+ * sparse series uses dark grey on black, on which reverse cursors may
+ disappear, usually looks better
+ * frugal series avoids dark grey
+ * slate for cterm now incorporates frugal-cterm-sisu
+ * [03073b7] v2 v3: bin/ type fix for ruby version check
+ * [416d0ec] v2 v3: manpage, reinstate escaping of hyphens
+ * [6b0a64f] v*: manpages escaped hyphens reinstated
+ * [5fa19b6] v2 v3: note (CHANGELOG) on ruby DBI bug affecting sisu cgi sample
+ search forms
+ * see <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596103> however, it
+ affects sqlite3 in the same way as pgsql (the driver against which it is
+ reported)
+ * includes possible workarounds (for sisu sample search forms)
+ * [6a20d40] v2 v3: bin/ cosmetic
+ * [75e80f2] v2 v3: vim colorschemes minor review
+ * [9a9c366] v3: concordance, output path, screen info correction
+ * [46eebe8] v3: options, language setting, based on directory structure or
+ filename
+ * affects multiple libraries
+ * [8ece506] v3: i18n, sysenv, options, language setting changes
+ * must be able to set language at options stage from filename or directory
+ * affects many files
+ * old i18n more appropriately renamed prog_text_translation
+ * [5f0bc4a] v3: urls, sqlite, a fix
+ * [2d79257] v3: db, review, directory structure changed, database prefix
+ renamed
+ * language_document_char field made larger [consider renaming]
+ * title, src_filename and language_document_char fields mandatory
+ (title, title_main, src_filename, language_document_char)
+ * review of unique key setting, now based on combination of filename
+ and language (filename no longer sufficient with intro of language
+ subdirectories)
+ * [retest sqlite3]
+ * [c7c3ab1] v3: sample search form, revert to generating ruby 1.8.7 sample
+ * sisu3 using ruby >=1.9.2p180 generates search form for ruby 1.8.7, so:
+ generate sample form using sisu3 -F (options), then; start webrick using
+ ruby 1.8.7 & sisu -W (not sisu3)
+ * take account of alternative output directory structures [work on, test]
+ * [e54612b] v3: date, version, changelog
+ * [8b7a793] v3: i18n, sysenv, class variable to prevent unnecessary
+ re-construction of hash
+ * prevent program from becoming as slow as treacle, a fix
+ * [b08d064] debian/control, Standards-Version 3.9.2
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 05 May 2011 22:15:02 -0400
+
+sisu (3.0.7-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [54b31e1] sha256 (3.0.6)
+ * [2dec156] v3: 3.0.7 version & changelog "opened"
+ * [cc1c683] v3: urls, reuse/share code, fix -U
+ * share code between show selected urls and show all urls
+ * fix -U which has not been properly updated for v3
+ * [1f36048] v3: dates - version, changelog; v2: 2.9.2 opened - version,
+ changelog
+ * [a7413a2] v2 v3: vim slate colorscheme, conflicting group colors reviewed
+ * [ccc3355] v2 v3: vim cterm colorschemes "8" and "frugal" added
+ * [2dcb16c] v3: screen_text_color (ansi colors) touched, consider reviewing
+ later
+ * [5b647bd] v2 v3: cgi, sample-search-form
+ * results still not right, (ruby1.9.2 libraries? double check script)
+ * not yet done variable directory path fixing for result links
+ * [ba81996] v2 v3: options, -M / --maintenance, new alias
+ --keep-processing-files
+ * new alias --keep-processing-files (see Bug#622902)
+ * document "--keep-processing-files" alias for "-M" ("--maintenance")
+ * minor rearrangement of regex
+ * (Closes: #622902)
+ * [f330953] v3: odf:odt processing in separate subdirectories
+ * processing in separate subdirectories that can be kept for maintenance
+ * odt.zip (bin) directory renamed odt from odf
+ * sysenv, odf:odt paths adjusted for changes in maintenance & odt.zip
+ * [dcfbef6] v3: urls, minor fixes
+ * fix maintenance urls -M (where processing files are kept for examination)
+ * odf maintenance added
+ * [17d1555] v3: options, hub, introduce opt.act booleans, more setting in
+ options
+ * opt.act booleans more flexible than opt.cmd
+ (start to favor use of opt.act over opt.cmd)
+ * move option setting from hub to options where possible
+ * separate out a few methods
+ * [44464e2] v3: param, md remove md.cmd and md.mod shortcut methods, use use
+ md.opt
+ * affects many files that now use @md.opt.cmd & @md.opt.mod
+ (instead of @md.cmd & @md.mod)
+ * [cc7bc6d] v3: harvest, sysenv, place with document manifests, variable
+ directory path
+ * sysenv, variable directory path fixing (language, filetype, filname),
+ making the stub for at least manifest and html available early for
+ processing that do not or should not need to process individual markup
+ files completely, such as the cgi search form and harvest
+ * harvest
+ * place with document manifests
+ * variable directory path fixing (language, filetype, filname)
+ * [4bc8b76] v2 v3: vim colorschemes, headers touched, url to git repo provided
+ * [0797659] v2 v3: sisu-mode.el, header notes copyright assignment to FSF
+ (GNU EMACS)
+ * assignment to FSF
+ * header includes url to git repo (when possible track GNU EMACS location)
+ * [c1fe197] debian/sisu.lintian-overrides update for current lintian
+ (v2.5.0~rc2)
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 20 Apr 2011 21:45:15 -0400
+
+sisu (3.0.6-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [2d6d497] sha256 (3.0.5-3)
+ * [b0955dc] v2, v3: 3.0.6 version & changelog "opened"
+ * [350efc6] v2: param, nested regex match fix (backport from v3)
+ * [9542185] v2, v3: sysenv, remove repeated method
+ * [d5d39d4] v2, v3: cgi, sample-search-form, string output
+ * ruby1.9.2 transition related
+ * (+ clean unused help text)
+ * [709e806] v2, v3: dal_images, image path setting
+ * ruby1.9.2 transition related
+ * [b06c1e8] v2, v3: dal_doc_str, empty line not paragraph object
+ * ruby1.9.2 transition related
+ * [af4d521] v2, v3: dal_doc_str.rb, table structure issue
+ * ruby1.9.2 transition related
+ * double spaced empty line creates spurious newline
+ * [6324d3d] vim colorscheme slate, review console colors
+ * [ebd803a] vim colorscheme slate, rearrange
+ * [9556ce0] debian/control, depends, graphicsmagick if not imagemagick
+ * [ef757f1] debian/bin/sisu* force use of 1.9.2, guarantee dependencies
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 30 Mar 2011 23:52:16 -0400
+
+sisu (3.0.5-3) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * build -3 with source .orig.tar.gz for upload to debian
+ (displace -1 & -2 that were not uploaded, debian/changelog merged)
+ * [663832e] sha256 (3.0.5-2) - not uploaded
+ * [90bf54d] sha256 (3.0.5-1) - not uploaded
+ * [43cd90d] debian/control correct new ruby depends
+ * [778bcb6] modify sisu shebang for debian
+ * debian/bin modify shebang #! /usr/bin/ruby1.9.1 for current ruby 1.9.2
+ * debian/sisu.install use debian/bin
+ * [f577abb] sha256 (3.0.4)
+ * [21cadb8] v3: changelog & version 3.0.5
+ * [18eefb2] v2, v3: vim syntax highlighting, fix typo
+ * [9e82cce] v3, v2: bin/sisu*: v3 development ruby >=1.9.2p180;
+ v2 maintenance ruby >=1.8.7
+ * bin/sisu* version checks
+ * [e5d3440] v2, v3: texpdf bugfix, where map_nametags not found, drop tag,
+ rather than crash
+ * Debian-live, live-manual (Ben Armstrong, chals?, reported new bug in a
+ number of translations (that crashed the pdf generator). It turns out
+ where map_nametags is not found the document crashes. Fix.
+ * [98a76bd] debian/control depends ruby (>= 1.9.2.180) debian ruby 1.9.1 libs;
+ current sisu
+ * Depends: ruby (>= 1.9.2.180)
+ * Depends: debian ruby 1.9.1 libraries
+ * Depends: current version of sisu for (sisu-pdf sisu-postresql sisu-sqlite)
+ (= ${source:Version}) [sisu-complete already does so]
+ [sisu (v2 especially) requires extensive testing, to see that it behaves as
+ it should with ruby 1.9.2 and associated required libraries]
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 27 Mar 2011 20:21:13 -0400
+
+sisu (3.0.5-2) unstable; urgency=low
+
+ * not uploaded to debian, merged into 3.0.5-3
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 26 Mar 2011 14:09:33 -0400
+
+sisu (3.0.5-1) unstable; urgency=low
+
+ * not uploaded to debian, merged into 3.0.5-3
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 24 Mar 2011 20:37:26 -0400
+
+sisu (3.0.4-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [32f83cb] sha256 (3.0.3)
+ * [e19720c] v3: changelog & version 3.0.4
+ * [1c052f5] sisu_manual, sisu_download, remove references to versions of sisu
+ * [0129345] debian/control depends ruby (>=1.8.7)
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 11 Mar 2011 17:07:44 -0500
+
+sisu (3.0.3-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [589d36b] sha256 (3.0.2)
+ * [9dea2a8] v2, v3: 3.0.3 version & changelog "opened"
+ * [7817075] v2, v3: texpdf, url (regex) pattern match fix
+ * [755acef] v2, v3: dal_syntax + downstream output, email regex revised
+ * revised pattern match for email address, (removes occasional interference
+ with urls having embedded email addresses) (dal_syntax and affected
+ downstream output modules)
+ * [259351d] v2, v3: dal_syntax: (internal document) link matching, a fix.
+ [Debian-live, live-manual (Jose Luis Zabalza, Ben Armstrong], reported bug
+ in Spanish translation markup (that crashed the pdf generator). Bug in
+ markup subsequently identified as "versátil,#{iso-hybrid}#, se" which the
+ interpreter identified as an internal document link to a comma (instead
+ of as being monospace markup), markup should have been "versátil,
+ #{iso-hybrid}#, se" this fix prevents that incorrect match, (but the
+ markup remains faulty and the monospace markup is not identified as such
+ without the corrected spacing). Unfortunate "grave" results for what is
+ a pretty insignificant data entry typo (there are no doubt other such
+ situations).]
+ * [63251bd] v2, v3: dal_substitutions_and_insertions: sisu header matching in
+ codeblock, fix
+ * [cbcf26c] v2, v3: dal_doc_str: fix, looks like typo in regex
+ * [93308a6] v3 (v2): manpage, param, urls: manpage output presentation fixes
+ * manpage: lowercase .br; correct newlines before .nf and after .fi; no
+ escape of hyphens; remove redundant links; endnotes array requires
+ flatten; screen info on output path)
+ * param: manpage header .br and no escape of hyphens
+ * urls: correct output path for manpage
+ * [e4ca6d0] v2, v3: help (markup): correct path to markup-samples
+ * [a6042b0] documentation more link fixes (remove redundant), remove repeated
+ skin
+ * [57ad1a1] manpage: sisu.1 and html regenerated
+ * [d3a0924] param: tidy, remove redundant document header tags
+ * [61c7438] syntax highlighting updates, emacs, vim
+ * emacs sisu headers updated (subheaders omitted for now) sisu-mode.el
+ * vim cleaning sisu.vim
+ * [bfa2a01] v2, v3: changelog git.sisudoc.org tag-points [3.0.3-1]
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 11 Mar 2011 08:22:59 -0500
+
+sisu (3.0.2-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+ * [a6673bc] sha256 (3.0.1)
+ * [494b0b5] v2: changelog fix
+ * [a800c2b] v3: urls, param, two unrelated regex fixes, check
+ * [abaab64] v3: hub, minor rearrangement
+ * [baa7f20] v3: changelog, open 3.0.2, target ruby1.9.2
+ * [af2ffd7] v3: sisu version 3.0.2-beta-rb1.9.2p180
+ * [0aff055] make sisu: v2 require >=ruby1.8.7; v3 require >=ruby1.9.2
+ * bin/sisu bin/sisu3 modified accordingly
+ note: there are issues with sisu and early versions of ruby1.9.2
+ ruby1.9.2p0 is known to segfault on a number of operations
+ ruby1.9.2p180 does not have these issues
+ * v3 includes changelog updates
+ * v2 includes changelog updates and version update 2.8.1
+ * [d4c0675] v3: use "encoding: utf-8" (instead of coding)
+ * [f09f45a] v3: use rb1.9.2 "require_relative" syntax
+ * [05a3fd2] v3: ruby 1.9 hash symbol syntax adopted
+ * [f2ab439] v3: space between each and opening curly brace
+ e.g. "x.each {|y| p y}"
+ * [5abc572] v3: sysenv, separate out processing_path method plus consequences
+ * [59b7f84] v2, v3: consolidate manual & markup samples
+ * reinstate lang dir structure for manual when v3 becomes default
+ * [572064e] CHANGELOG_v{1,2,3}, syslink, avoid duplication
+ * CHANGELOG_v3 updated
+ * CHANGELOG & README locations pruned
+ * [6cc4670] debian related sisu markup samples, reorganise
+ * [ceb35ac] conf/skin prune skins
+ * remove less important skins
+ * use syslink to share doc/skin_sisu.rb
+ * [73c312d] v3: version & changelog, touch date
+ * [278c945] v2, v3: defaults, default homepage tidy & update links
+ * [a512dfe] v2, v3: manpage, adjust output (backslash ('\') escapes reduced)
+ * [b972304] doc/sisu user_txt, minor update & pruning
+ * [c9440e3] markup samples, manual, headers: links and other details
+ * [cce96b7] manpages: sisu.1 update; sisu_vim.7 cleaning
+ * [f3aefad] sisu.8 manpage & html deleted, needs rewrite, unhelpful
+ * [0c872f4] html manpages, re-run man2html
+ * [1ffd1da] documentation, remove some files
+ * [5b12491] manpage + html: sylink sisu.1 to sisu3.1
+ * [02c1669] documentation, minor tidy
+ * [6991d5a] v2, v3: changelog updates
+ * [8050926] debian/sisu.manpages, remove sisu.8
+ * [8fc0343] debian/control linebreaks, cosmetic
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 05 Mar 2011 22:28:21 -0500
+
+sisu (3.0.1-1) unstable; urgency=low
+
+ [ Ralph Amissah ]
+
+ * debian/control sisu-complete, pull current version of sisu
+
+ * debian/{compat,control} update debhelper to version 8
+
+ * sysenv, sisurc.yml and elsewhere as affected, output_dir_structure:
+ by_language_code; by_filetype; by_filename
+
+ * css, fix css paths for xhtml, xml dom & xml sax
+
+ * console feedback on selected files being processed, updates & fixes
+
+ * sysenv & sisurc.yml: libreoffice, default odf reader
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 16 Feb 2011 21:32:25 -0500
+
+sisu (3.0.0-1) unstable; urgency=low
+
+ [ Ralph Amissah ] - post squeeze
+
+ * opening of version 3 unstable/development branch, (which provides
+ alternative output directory structures and file naming, and starts attempt
+ at 'po' output) see upstream v3 changelog. Processing defaults to v2, v3 is
+ accessible using 'sisu3' or 'sisu --v3' (followed by usual instructions)
+ [note: once v3 is ready v2 branches will be retired]
+
+ * closing of v1 legacy branch
+
+ * sisu2 & sisu3 added to /usr/bin, along with sisu-git and sisu-po; all added
+ to sisu.install
+
+ * new manpages provided, sisu2 sisu3 sisu-po
+
+ * debian/sisu.install includes new
+
+ * lintian overrides extended to cover v3
+
+ * use debian source format 3.0, debian/source/format 3.0 (quilt)
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 07 Feb 2011 10:53:18 -0500
+
+sisu (2.7.9-1) unstable; urgency=medium
+
+ [ Ralph Amissah ] - debian freeze, code fixes
+ (most of them requested for debian live-manual)
+
+ * dal, fix missing multi-line regex matches for line-wrap text
+ (live-manual, to work better with po4a)
+ * dal_doc_str, bulleted text (and headings), multi-line match, to permit
+ line-wrapped paragraphs
+ (requested fix, Ben Armstrong (live-manual))
+ * dal_syntax, multi-line match for fontface markup (emphasis, bold,
+ italics, underscore etc.)
+
+ * texpdf, use of monospace in headings causes table of contents breakage, fix
+ (requested fix, Ben Armstrong (live-manual))
+
+ * texpdf, toc now contains level 3~ consistent with other output formats
+ (requested fix, Ben Armstrong (live-manual))
+
+ * html & css, ocn (object numbers) now link to themselves, clicking on one
+ places that object at the top of the browser and provides its url
+ (requested, Ben Armstrong (live-manual))
+
+ * epub, ocn (object numbers) now link to themselves, clicking on one
+ places that object at the top of the viewer
+
+ * document manifest links
+ * html, link to "document manifest" remains (links to individual output
+ types removed)
+ * plaintext, link to "document manifest" fix (links to individual output
+ types removed)
+ * odf, manifest link fix
+
+ * html search form, configuration check
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 09 Dec 2010 12:59:51 -0500
+
+sisu (2.7.8-1) unstable; urgency=medium
+
+ [ Ralph Amissah ] - debian freeze, code fixes
+
+ * i18n, introduce header @make: :language: internationalization using codes
+ from http://www.debian.org/international/l10n/po/ at this time for texpdf,
+ (able to satify needs of polyglossia for the likes of Brazilian Portugues)
+ and in future for po files, where iso:639 for this purpose appears to have
+ use limitations http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
+ * param, extract @make: :language: information if provided, default
+ "english"
+ * i18n, add code list and associated language (as listed by polyglossia)
+ * texpdf_format, use param (@make: :language: (default english)), to set
+ tex document language header (previously used file naming convention)
+ * sisu.vim recognize @make: :language:
+ (also elsewhere shortened :lang_code: from :language_code:)
+
+ * internal links
+ * dal, exclude parentheses and square brackets from matching
+ (requested fix, Ben Armstrong)
+ * html, remove space between link & following punctuation, parentheses &/or
+ square brackets
+ (requested fix, Ben Armstrong)
+ * epub, remove space between link & following punctuation, parentheses &/or
+ square brackets
+
+ * html
+ * remove "copy @" mark
+ (requested, Daniel Baumann)
+ * segments, title banner (including "copy @" mark) configurable, boolean,
+ true/false (default false)
+ (requested off option, Daniel Baumann)
+ * quick ref links_guide configurable, boolean, true/false (default false)
+ (requested off option, Daniel Baumann)
+
+ * config.yml
+ * html, seg title banner, boolean true/false setting (commented out,
+ default false)
+ * html, quick_ref, boolean true/false setting (commented out, default
+ false)
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 30 Oct 2010 23:49:39 -0400
+
+sisu (2.7.7-1) unstable; urgency=medium
+
+ [ Ralph Amissah ] - debian freeze, code fixes
+ * codeblocks, numbered markup option, fix
+ (requested fix needed by debian-live:live-manual, Ben Armstrong, Mark
+ Schneider, Daniel Baumann)
+ * texpdf, codeblocks do not permit empty lines, fix
+ * texpdf, bullet text, hanging indent, (regular (not grouped) text), fix
+ (requested fix, Ben Armstrong)
+ * texpdf, first space following a bullet should be fixed width, fix
+ (requested fix and suggested solution, Ben Armstrong)
+ * documentation related minor updates and fixes
+ * changelog & version updates
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 17 Oct 2010 13:37:55 -0400
+
+sisu (2.7.6-1) unstable; urgency=medium
+
+ [ Ralph Amissah ] - debian freeze, code fixes
+ * texpdf, codeblocks, code-line continuation backslash dropped, fix
+ (requested fix, Ben Armstrong)
+ * shared_metadata, odf, url characters to not match
+ * sisu_convert, basic conversion script, preliminary fix
+ * CHANGELOG v2, recount where some requests came from
+ * changelog & version updates
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 11 Oct 2010 22:43:27 -0400
+
+sisu (2.7.5-1) unstable; urgency=medium
+
+ [ Ralph Amissah ] - debian freeze, code fixes
+ * odt fix cornercase breakage matching and representing "&nbsp", "&" and urls
+ * odf, "&nbsp" and "&"
+ (prior to this fix, odt for viral_spiral is broken in sisu-markup-samples)
+ * shared_metadata, "&nbsp", "&" and urls in metadata
+ more consistent open document text results
+ * param, metadata rights, keep colon separator from interfering with urls
+ * changelog & version updates
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 09 Oct 2010 23:18:59 -0400
+
+sisu (2.7.4-1) unstable; urgency=medium
+
+ [ Ralph Amissah ] - debian freeze, code fixes
+ (requested fixes related to image scaling; behaviour testing & request by
+ Mark Schneider)
+ * epub (epub_tune) scaling of images, fix
+ * html (html_tune) scaling of images, fix
+ * odf:odt, incorporation and scaling of images, fix
+ * texpdf, scaling of images (below the set max size), fix
+ * changelog & version updates
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 08 Oct 2010 19:38:12 -0400
+
+sisu (2.7.3-1) unstable; urgency=medium
+
+ [ Ralph Amissah ] - debian freeze, code fixes (& minor documentation fix)
+ * dal_images, where image dimensions are set in an object, use those
+ (requested fix, behaviour testing & request by Mark Schneider)
+ * hub, fix sisu breakage when -y (manifest) is run without the explicit or
+ implicit calling of -m (creation of document abstraction for processing),
+ (e.g. when --source or --sisupod is called on its own).
+ * urls, cleaning
+ * a few aliases added (long options)
+ * sisu_markup.sst, document a fix (v1 & 2)
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 07 Oct 2010 10:04:02 -0400
+
+sisu (2.7.2-1) unstable; urgency=medium
+
+ [ Ralph Amissah ] - debian freeze, code fixes
+ * hub, test whether user name set
+ (requested fix, provided by Ben Armstrong)
+ * epub, fix breakage where angle brackets used in used metadata header
+ * texpdf_format, remove a few commented out lines
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 01 Oct 2010 23:45:58 -0400
+
+sisu (2.7.1-1) unstable; urgency=medium
+
+ [ Ralph Amissah ] - debian freeze, code fixes
+ * shared_metadata, odt fix breakage where angle brackets used in metadata
+ headers; & a typo fix
+ (requested fix)
+ * manifest, typo fix
+ * param, a few fixes (checks, aliases, typo)
+ * hub, removed commented out option (git), (already enabled elsewhere)
+ * share_src, remove repetition, redundancy
+ * texpdf, a5, increase headheight (fix issues where header wrapped)
+ * texpdf, provide line-break-points for long directory names
+ (requested fix)
+ * texinfo, urls cleaned & with angle bracket decoration
+ * texinfo ocn decoration a hash (instead of angle braces)
+ * texinfo_format, texinfo output broken, fix (Closes: #598063)
+ (requested fix)
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 01 Oct 2010 09:40:57 -0400
+
+sisu (2.7.0-1) unstable; urgency=low
+
+ [ Ralph Amissah ] - debian freeze, 2.7.0-1 moves 2.6.3-6 upstream
+ * CHANGELOGs updated and reported version changed (else as in 2.6.3-6)
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 24 Sep 2010 20:31:06 -0400
+
+sisu (2.6.3-6) unstable; urgency=low
+
+ [ Ralph Amissah ] - debian freeze, code fix, (documentation, minor fixes)
+ * html, v2 update (including --long-options) (manpage sync adds files)
+ * manpage, v2 update (including --long-options)
+ * sisu_commands.sst v2 update (including --long-options)
+ * help, minor update, revisit (includes minor fixes)
+ * identify markup, update ... revisit
+ * urls, sysenv, set manpage viewer to "man"
+ * options, bullet proof matches for --long-options (effects minor fix)
+ fixes issue noted with --sample-search-form (-F) (in the selection of
+ webrick (--webserv-webrick))
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 20 Sep 2010 18:18:00 -0400
+
+sisu (2.6.3-5) unstable; urgency=medium
+
+ [ Ralph Amissah ] - debian freeze, code fix, (boilerplate code addition)
+ * epub, fix xhtml line-break in rights metadata, results in unreadable epub
+ (Closes: #596736) epub output not readable by all epub-reader software (else
+ epub output can be viewed in calibre, but not in fbreader or okular)
+ * options, add expressive options "--[name]" as alternative to flags "-[x]"
+ (boilerplate addition)
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 13 Sep 2010 15:27:11 -0400
+
+sisu (2.6.3-4) unstable; urgency=medium
+
+ [ Ralph Amissah ] - debian freeze, code and documentation fixes
+ * html_format, xml_format, reduce visibility of sisu in output
+ * yml metadata, add subheading for a title
+ * html headers do not include the "title" field, fix (Closes: #594949)
+ (param, variable not set (presumably since change from v1 to v2))
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 31 Aug 2010 09:57:21 -0400
+
+sisu (2.6.3-3) unstable; urgency=medium
+
+ [ Ralph Amissah ] - debian freeze, documentation related changes only
+ * minor cleaning of headers (& a fix in book index) in document markup sample
+ free_as_in_freedom...
+ * update of some links in free_as_in_freedom... list.yml promo.yml
+ * debian document markup samples, add copyright and license information
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 23 Aug 2010 09:54:33 -0400
+
+sisu (2.6.3-2) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * debian/control, sisu-pdf, Depends on texlive-xetex added (Closes: #590766),
+ replacing Recommends
+ * debian/control, sisu-pdf, Depends on lmodern added (Closes: #590767)
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 29 Jul 2010 01:00:11 -0400
+
+sisu (2.6.3-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * debian/control, Standards-Version 3.9.1
+ * debian/control, Maintainers, Uploaders and Homepage fields updated
+ * odf, footnotes, asterisk series (**) fix
+ * html_format, epub_format: subtoc, footnote content bug (fix)
+ * odf: lt (<), gt (>) fix for codeblocks; &amp fix, messy
+ * epub_format, removed some title & author info, check
+ * epub_tune, <br /> (from <br>)
+ * epub_format, within head, title & author
+ * epub, toc copyat link removed
+ * manifest, defaults, minimal sisu footer
+ * hub, add metaverse run for git (composite files)
+ * git, param, refine filename regex for composite files
+ * git sisu directory structure, lang dir beneath txt
+ * html, links to output formats, remove icons
+ * minitoc sisurc configurable (true/false)
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 28 Jul 2010 14:51:56 -0400
+
+sisu (2.6.2-2) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * debian/control update ruby1.9 related depends to ruby1.9.1 (affects
+ libfcgi-ruby)
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 17 Jul 2010 08:34:14 -0400
+
+sisu (2.6.2-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * param, make header reading more robust (against comments)
+ * texpdf, make easier to change or remove left footer
+ * texpdf, do not raise copymark (no superscript)
+ * texpdf, monospace, decide whether small size font is acceptable
+ * vim syntax, match bold in bulleted and indented text
+ * texpdf, remove copy @ when no such info provided
+ * param, lines breaks in rights all
+ * texpdf, asterisk
+ * sisu-harvest, sisu --harvest (with man page, & updated manpage references)
+ * texpdf, codeblocks, left margin flush
+ * html_segments, line space between end of text & bottom navigation bar
+ * debian/sisu.install & sisu.manpages include sisu-harvest
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 15 Jul 2010 07:41:41 -0400
+
+sisu (2.6.1-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * texpdf, monospace fix
+ * dal_syntax, monospace (avoid url match false positive)
+ * sysenv default output path fix
+ * html_scroll, deals with index & endnotes
+ * dal, manifest & metadata headings, non-substantive, ocn removed
+ * sisu_manual, minor cleaning
+ * debian additional markup samples (move directory)
+ * Merge branch 'upstream' into debian/sid
+ * markup-samples, remove content, non-modifiable etc.
+ * moved markup samples
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 09 Jul 2010 15:12:46 -0400
+
+sisu (2.6.0-1) unstable; urgency=medium
+
+ [ Ralph Amissah ]
+ * new upstream, see upstream changelog
+ * version.yml moved to /usr/share/sisu/v2/v (from /etc/sisu)
+ * alternative sisu command names for producing single output types
+ sisu-pdf, sisu-html, sisu-odf, sisu-epub, sisu-txt, sisu-pg, sisu-sqlite
+ * manpages added for command names
+
+ [ Daniel Baumann ]
+ * manpages added & update
+ * added year in copyright file for setup.rb
+ * update year in copyright file
+ * wrap depends in control to 80 chars per line
+ * use standards version to 3.9.0
+ * use Debhelper 7 minimized rules file
+ * prefix NEWS.Debian with package name
+ * removal of whitespace at eol
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 08 Jul 2010 08:02:18 -0400
+
+sisu (2.5.1-1) unstable; urgency=medium
+
+ * new upstream, a fix (xetex set program default font if none configured),
+ see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 12 Jun 2010 00:50:24 -0400
+
+sisu (2.5.0-1) unstable; urgency=medium
+
+ * new upstream, texpdf select font, default requires Liberation fonts be
+ installed, some other small fixes, see upstream changelog
+
+ * depends ttf-liberation
+
+ * suggests calibre
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 11 Jun 2010 22:08:47 -0400
+
+sisu (2.4.3-1) unstable; urgency=medium
+
+ * new upstream, makes vim ftplugin a bit less intrusive, see upstream
+ changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 05 Jun 2010 20:25:50 -0400
+
+sisu (2.4.2-1) unstable; urgency=medium
+
+ * new upstream, small adjustments, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 01 Jun 2010 22:57:22 -0400
+
+sisu (2.4.1-1) unstable; urgency=medium
+
+ * new upstream, small fixes, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 26 May 2010 19:19:29 -0400
+
+sisu (2.4.0-1) unstable; urgency=medium
+
+ * new upstream, internal document linking, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 26 May 2010 15:40:43 -0400
+
+sisu (2.3.5-1) unstable; urgency=medium
+
+ * new upstream, small fixes, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 18 May 2010 22:50:23 -0400
+
+sisu (2.3.4-1) unstable; urgency=medium
+
+ * new upstream, small adjustments and fixes, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 13 May 2010 09:54:48 -0400
+
+sisu (2.3.3-1) unstable; urgency=medium
+
+ * new upstream, small adjustments and fixes, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 05 May 2010 18:35:48 -0400
+
+sisu (2.3.2-1) unstable; urgency=medium
+
+ * new upstream, small adjustments and fixes, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 03 May 2010 19:18:35 -0400
+
+sisu (2.3.1-1) unstable; urgency=medium
+
+ * new upstream, one line fix, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 28 Apr 2010 00:20:35 -0400
+
+sisu (2.3.0-1) unstable; urgency=medium
+
+ * new upstream including sql db structure change, addition of oclc number
+ (v2c), disruptive where sisu search is used it is necessary to recreate db
+ and tables and populate; search forms must be redone to take account of db
+ changes; release includes many small fixes, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 27 Apr 2010 19:51:23 -0400
+
+sisu (2.2.0-1) unstable; urgency=medium
+
+ * new upstream, sql db structure changes (v2b), disruptive where sisu search
+ is used it is necessary to recreate db and tables and populate; search
+ forms must be redone to take account of db changes; release includes many
+ fixes, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 20 Apr 2010 19:33:31 -0400
+
+sisu (2.1.0-1) unstable; urgency=medium
+
+ * new upstream, sql db structure changes, disruptive must recreate db and
+ tables and populate; search forms must be redone to take account of db
+ changes; release includes fixes, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 16 Apr 2010 11:31:54 -0400
+
+sisu (2.0.5-1) unstable; urgency=medium
+
+ * new upstream, minor fix release, see upstream changelog
+ [inter alia: harvest topics; manifest search form for db; sql search form;
+ db_create issue for sqlite]
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 31 Mar 2010 19:46:01 -0400
+
+sisu (2.0.4-1) unstable; urgency=medium
+
+ * new upstream, minor fix release, see upstream changelog
+ [inter alia re: use of param title.full, [fix occasional sql load
+ breakage]]
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 23 Mar 2010 19:46:41 -0400
+
+sisu (2.0.3-1) unstable; urgency=medium
+
+ * new upstream, minor fix release, see upstream changelog
+ [inter alia fix to occasional odf:odt breakage]
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 22 Mar 2010 20:11:15 -0400
+
+sisu (2.0.2-1) unstable; urgency=medium
+
+ * new upstream, minor fix release, see upstream changelog
+ [inter alia fix to occasional sql load breakage]
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 21 Mar 2010 11:27:21 -0400
+
+sisu (2.0.1-1) unstable; urgency=medium
+
+ * new upstream, minor fix release, (most significant related to html tables)
+ see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 17 Mar 2010 15:44:23 -0400
+
+sisu (2.0.0-1) unstable; urgency=low
+
+ * new upstream, introducing v2 with new middle layer and downstream
+ libraries; includes epub output
+
+ * sisu v2 installed by default as sisu
+
+ * debian/sisu.install now installs version 1 and version 2 libraries
+
+ * debian/control package description adds mention of Epub output introduced
+ with this version
+
+ * same lintian overrides added to version 2 as were in version 1, some sample
+ scripts are provided as text, and not intended to be executable
+
+ * debian News provided for this version, warning of incompatibility with
+ version 1 markup, brought about by change to document header
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 06 Mar 2010 06:50:00 -0500
+
+sisu (1.0.3-1) unstable; urgency=medium
+
+ * upstream, plaintext footnote / endnote fix, and in sample skins
+ specification of utf-8 (in some cases needed by ruby 1.9.1)
+
+ * move ruby 1.9 branch to 1.9.1 from 1.9.0 (this should address #569888, if
+ not reopen) (Closes: #569888)
+
+ * update standards version to 3.8.4 (from 3.8.3)
+
+ * medium urgency retained (previous upload transition to testing prevented by
+ #569888)
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 17 Feb 2010 11:06:01 -0500
+
+sisu (1.0.2-1) unstable; urgency=medium
+
+ * upstream, sample markup document, markup modified, affects document
+ numbering
+
+ * medium urgency retained, as impedes progress of previous upload,
+ (modification needed for future consistency)
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 10 Feb 2010 16:51:20 -0500
+
+sisu (1.0.1-1) unstable; urgency=medium
+
+ * upstream contains an odf fix
+
+ * markup samples directory structure, minor adjustments, (and no longer
+ shared by package sisu_markup_samples, about which, see that package)
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 08 Feb 2010 21:45:17 -0500
+
+sisu (1.0.0-1) unstable; urgency=low
+
+ * version 1 declared and directory structure modified to allow parallel
+ development of version 2, through introduction v1 directories where
+ needed (the moving of sample markup files helps account for large
+ diffs)
+
+ * sisu markup, old style header support dropped to simplify and make cleaner
+ introduction of version 2 headers, (i.e./e.g. old style headers like
+ '0~title' are no longer supported, use '@title:')
+
+ * debian/sisu.install explicit mention of a number of files to make debian
+ switch to version 2 trivial
+
+ * debian/control "conflicts" and "replaces" versions of sisu-markup-samples
+ (non-free, due to copyright restrictions on modifying original text) 1.0.11
+ and older due to package directory structure changes
+
+ * debian/control "recommends" removed for hyperestraier; "suggests" removed
+ for kdissert
+
+ * debian/sisu.lintian-overrides, maintained with changed directory structure
+
+ * documentation, modified description of command flags -m and -n (in line
+ with communication on bug report) (Closes: #555496)
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 20 Dec 2009 19:05:08 -0500
+
+sisu (0.71.4-1) unstable; urgency=low
+
+ * new upstream, sql fix, population of databases see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 29 Aug 2009 23:46:52 -0400
+
+sisu (0.71.3-1) unstable; urgency=low
+
+ * new upstream with fix to use imagemagick directly (when imagemagick is
+ available and rmagick declares versions not in sync)
+
+ * switch to latest Standards-Version 3.8.3
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 28 Aug 2009 16:02:11 -0400
+
+sisu (0.71.2-1) unstable; urgency=low
+
+ * new upstream with a couple of fixes, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 02 Aug 2009 12:01:28 -0400
+
+sisu (0.71.1-1) unstable; urgency=low
+
+ * new upstream with relatively minor adjustments that are nonetheless worth
+ including, see upstream changelog
+
+ * debian/control added imagemagick as ruby 1.9.* rmagick package not yet
+ available program will system call imagemagick identify where needed
+ directly in absence of rmagick
+
+ * debian/sisu.install make libraries available to ruby 1.9 currently 1.9.0
+ (commencement of further testing awaits imminent upload ruby 1.9.1 and
+ subsequent build)
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 24 Jul 2009 21:33:56 -0400
+
+sisu (0.71.0-1) unstable; urgency=low
+
+ * upstream lib/sisu version directory moved from v0 to v1
+
+ * upstream housekeeping, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 09 Jul 2009 10:45:01 -0400
+
+sisu (0.70.6-1) unstable; urgency=medium
+
+ * fixes to sql interface
+
+ * fix to generated sample search form
+
+ * debian/control sisu-pdf Suggests: evince | pdf-viewer (Closes: #516714)
+
+ * switch to latest version of Debian Policy
+ (Standards-Version 3.8.2 instead of 3.8.0)
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 01 Jul 2009 10:58:47 -0400
+
+sisu (0.70.5-1) unstable; urgency=low
+
+ * new minor upstream release, see upstream changelog
+
+ * debian/ new year cleaning:
+ * debian/copyright use parse-able format;
+ * debian/rules cleanup;
+ * debian/control fcgi-ruby made a dependency for sisu-postgresql and
+ sisu-sqlite as sample script needs it, git repo move noted, package
+ description touched;
+ * removed sisu.postrm, forced removal on purge /etc/sisu draconian if
+ it contains admin edits
+ * minor sorting
+
+ * note git repo moved:
+ <http://git.sisudoc.org/?p=code/sisu.git;a=summary>
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 18 Jan 2009 00:38:58 -0400
+
+sisu (0.70.4-1) unstable; urgency=medium
+
+ * new upstream, see upstream changelog, sisu-pdf, workaround necessitated by
+ texlive behaving differently with tilde characters, similar to recent issue
+ with tetex behavior with "bullet" mark
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 31 Dec 2008 00:35:29 -0400
+
+sisu (0.70.3-1) unstable; urgency=medium
+
+ * new upstream, see upstream changelog, fixes to sqlite3 component and minor
+ fix and cosmetic modification to some html
+
+ * new dependency on libsqlite3-ruby, now used to populate sqlite3 db
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 24 Dec 2008 00:08:39 -0400
+
+sisu (0.70.2-1) unstable; urgency=medium
+
+ * new upstream, see upstream changelog, includes a fix and a minor
+ manpage/help update
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 16 Dec 2008 00:45:19 -0400
+
+sisu (0.70.1-1) unstable; urgency=medium
+
+ * new upstream, see upstream changelog, includes fixes, better integration of
+ harvest, and additional metadata fields
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 14 Dec 2008 00:31:23 -0400
+
+sisu (0.70.0-1) unstable; urgency=low
+
+ * new upstream, see upstream changelog, includes a sisu site metadata harvest
+ module, version bump for minor syntax alteration, introduction of a
+ formatting rule for header author / creator field
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 02 Dec 2008 23:58:12 -0400
+
+sisu (0.69.4-1) unstable; urgency=low
+
+ * new upstream, notably includes emacs highlighting for sisu sisu-mode.el
+ see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 04 Nov 2008 18:38:01 -0400
+
+sisu (0.69.3-1) unstable; urgency=low
+
+ * new upstream, see upstream changelog, contains minor fix in manifest
+ reporting of markup source files (sisupod (.zip) where provided)
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 10 Oct 2008 22:28:11 -0400
+
+sisu (0.69.2-1) unstable; urgency=low
+
+ * new upstream, see upstream changelog
+ (sample sisu markup "Free as in Freedom": book index markers included)
+
+ * [debian/changelog corrected previous entry for 0.69.1 (which was a
+ repetition of 0.69.0)]
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 19 Sep 2008 19:08:16 -0400
+
+sisu (0.69.1-1) unstable; urgency=low
+
+ * new upstream, contains fix, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 17 Sep 2008 00:08:08 -0400
+
+sisu (0.69.0-1) unstable; urgency=low
+
+ * new upstream, see upstream changelog, many changes
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 16 Sep 2008 00:38:28 -0400
+
+sisu (0.68.0-1) unstable; urgency=medium
+
+ * new upstream, should be easier to maintain, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 22 Jul 2008 20:03:58 -0400
+
+sisu (0.67.5-1) unstable; urgency=medium
+
+ * texpdf fixes (xetex xelatex processing instruction and for A5 landscape),
+ see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 12 Jul 2008 14:49:02 -0400
+
+sisu (0.67.4-1) unstable; urgency=medium
+
+ * fixes (remote source files, default processing directory), see upstream
+ changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 12 Jul 2008 01:09:52 -0400
+
+sisu (0.67.3-1) unstable; urgency=medium
+
+ * fixes, (help env and fix of pdf papersize), see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 03 Jul 2008 23:04:30 -0400
+
+sisu (0.67.2-1) unstable; urgency=medium
+
+ * upstream fix for xetex landscape pdfs
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 02 Jul 2008 22:13:02 -0400
+
+sisu (0.67.1-2) unstable; urgency=medium
+
+ * package updated to follow the last version of Debian Policy
+ (Standards-Version 3.8.0 instead of 3.7.3)
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 22 Jun 2008 23:53:28 -0400
+
+sisu (0.67.1-1) unstable; urgency=low
+
+ * minor upstream update
+
+ * vim-addon policy compliance (Closes: #464824)
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 27 May 2008 19:34:22 -0400
+
+sisu (0.67.0-1) unstable; urgency=low
+
+ * new upstream, minor modification/simplification of markup syntax for files
+ imported to a composite/master document results in automatic version bump,
+ see upstream changelog and man pages
+
+ * vim syntax modified to reflect change in markup syntax
+
+ * debian / vim-addon-manager, investigate use of
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 22 May 2008 22:01:19 -0400
+
+sisu (0.66.3-1) unstable; urgency=low
+
+ * new upstream, see upstream changelog
+
+ * debhelper 7
+
+ * debian/control vcs info added
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 11 May 2008 14:29:34 -0400
+
+sisu (0.66.2-1) unstable; urgency=low
+
+ * new upstream, see upstream changelog
+
+ * ruby-dbi dependencies in sisu-postgresql ruby and sisu-sqlite refer to
+ ruby version 1.8
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 25 Apr 2008 04:44:31 +0100
+
+sisu (0.66.1-1) unstable; urgency=low
+
+ * new upstream, see changelog
+
+ * debhelper (>= 6)
+
+ * sisu-pdf recommends texlive-xetex
+
+ * [this changelog, cleaned trailing whitespaces]
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 30 Mar 2008 02:02:54 +0100
+
+sisu (0.66.0-1) unstable; urgency=low
+
+ * new upstream, (version bump markup tag related) see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 24 Feb 2008 22:44:20 +0000
+
+sisu (0.65.0-1) unstable; urgency=low
+
+ * new upstream, (version bump markup tag related) see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 16 Feb 2008 02:56:00 +0000
+
+sisu (0.64.4-1) unstable; urgency=low
+
+ * new upstream, minor, see changelog, (markup tag related)
+
+ * debian control description db names PostgreSQL and SQLite the former
+ requested by lintian
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 14 Feb 2008 06:11:58 +0000
+
+sisu (0.64.3-1) unstable; urgency=low
+
+ * new upstream minor, see changelog, (related to open source ecosystem
+ upgrade transition: ruby 1.9; postgresql 8.3 [interim])
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 06 Feb 2008 00:21:00 +0000
+
+sisu (0.64.2-1) unstable; urgency=low
+
+ * new upstream, minor, see changelog
+
+ * debian/control permit use with ruby 1.8 upgrade
+ (however limit retained on use with ruby 1.9)
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 19 Jan 2008 03:37:11 +0000
+
+sisu (0.64.1-1) unstable; urgency=medium
+
+ * new upstream with odf bugfix, see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 09 Jan 2008 06:16:44 +0000
+
+sisu (0.64.0-1) unstable; urgency=medium
+
+ * new upstream, see changelog, includes modifications to:
+ * processing files moved to user owned directory under
+ /tmp/_sisu_processing~
+ * newly created databases primary keys;
+ * postgresql populating affecting use of tcp/ip sockets;
+
+ * debian/sisu.postrm should fix #454372
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 02 Jan 2008 23:16:22 +0000
+
+sisu (0.63.0-1) unstable; urgency=medium
+
+ * new upstream, latex for pdf (landscape & portrait etc.) generated in single
+ pass [accounts for version bump], and contains rsync bugfix for sisupod
+ (remote placement, and for download and processing) [accounts for medium
+ urgency], see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 20 Dec 2007 00:25:51 +0000
+
+sisu (0.62.4-1) unstable; urgency=medium
+
+ * upstream with fix, and adjustment to gpl3 links
+
+ * debian build update
+
+ * debian/watch file
+
+ * DM upload
+
+ * gpg/pgp signature used changed (now B98F62B1 before BD76E77F)
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 14 Dec 2007 21:41:13 +0000
+
+sisu (0.62.3-3) unstable; urgency=medium
+
+ * Dm-Upload-Allowed field needs XS- prefex
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 30 Nov 2007 22:14:47 +0000
+
+sisu (0.62.3-2) unstable; urgency=medium
+
+ * debian/changelog (take more care with git reset)
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 29 Nov 2007 01:42:04 +0000
+
+sisu (0.62.3-1) unstable; urgency=medium
+
+ * new upstream with minor fixes, see changelog
+
+ * debian/control Dm-Upload-Allowed: yes
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 27 Nov 2007 02:43:18 +0000
+
+sisu (0.62.2-1) unstable; urgency=medium
+
+ * new upstream, minor, but contains a bugfix to do with remote markup source
+ that contains images, see changelog
+
+ * debian/control 'Homepage:' field (and accompanying lintian override)
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 03 Nov 2007 01:48:41 +0000
+
+sisu (0.62.1-1) unstable; urgency=medium
+
+ * new upstream with minor regex match fix, replaces previous as debian
+ upload
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 22 Oct 2007 19:42:07 +0100
+
+sisu (0.62.0-1) unstable; urgency=medium
+
+ * new upstream, several things, see upstream changelog
+
+ * some output directories moved that will require manual fixing for existing
+ sites, [outputpath]/_sisu/image_local becomes [outputpath]/_sisu/image;
+ [outputpath]/_sisu/image for system images becomes
+ [outputpath]/_sisu/image_sys; shared source if any now is placed in separate
+ directories, [outputpath]/src for shared markup text, [outputpath]/pod for
+ shared (zipped) sisupods [accounts for version bump]
+
+ * debian/control added 'Depends' on rsync (previously 'Recommends') as used
+ even more extensively
+
+ * debian/control, 'Replaces' and 'Conflicts' placed on sisu-doc sub-package
+ which was introduced for the duration of the 0.59 release series only,
+ (and never uploaded to Debian), [unlikely to exist, remove if it does]
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 20 Oct 2007 15:04:38 +0100
+
+sisu (0.61.0-1) unstable; urgency=medium
+
+ * new upstream, consolidates changes introduced in 0.59 and 0.60 series,
+ version bump due to change in treatment of available text outputs markup
+ shortcut, results now presented as a single object (changes the resulting
+ object numbering for document where used), includes some fixes
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 12 Oct 2007 20:59:45 +0100
+
+sisu (0.60.1-1) unstable; urgency=low
+
+ * new upstream with minor fixes
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 07 Oct 2007 14:22:08 +0100
+
+sisu (0.60.0-2) unstable; urgency=low
+
+ * debian/changelog, removed references to sisu-doc sub-package, (introduced
+ in 0.59 and removed again in 0.60)
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 04 Oct 2007 19:31:32 +0100
+
+sisu (0.60.0-1) unstable; urgency=low
+
+ * new upstream, contains a number of additions/fixes (see changelog) and
+ source tarball back to sane size (after 0.59 inflation, not in debian
+ archive), this includes sisu documentation as sisu source, but no generated
+ output, other than a few man pages, rationale for change provided in
+ upstream changelog
+
+ * [Note: previous 0.59 builds were not for debian upload]
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 03 Oct 2007 04:53:48 +0100
+
+sisu (0.59.1-1) unstable; urgency=low
+
+ * new upstream, minor fixes, see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 25 Sep 2007 03:14:21 +0100
+
+sisu (0.59.0-1) unstable; urgency=low
+
+ * new upstream, primarily documentation, new sub-package sisu-doc, increases
+ size of package considerably, many other changes, see changelog
+
+ * debian/control restrict ruby use: 1.8.4 < ruby < 1.9
+
+ * debian package specific manpages moved to main package
+
+ * debian note: lintian warnings on some sisu generated man-pages - certain
+ characters and line-breaks
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 23 Sep 2007 19:32:17 +0100
+
+sisu (0.58.3-1) unstable; urgency=low
+
+ * new upstream, minor detail, see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 06 Sep 2007 18:35:51 +0100
+
+sisu (0.58.2-1) unstable; urgency=low
+
+ * new upstream, detail, composite documents, code-block exception
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 05 Sep 2007 21:00:16 +0100
+
+sisu (0.58.1-1) unstable; urgency=low
+
+ * new upstream with minor fixes for grouped text (primarily code-blocks),
+ see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 04 Sep 2007 22:23:59 +0100
+
+sisu (0.58.0-1) unstable; urgency=low
+
+ * new upstream, mostly to do with escaping code-blocks from being marked up,
+ see changelog
+
+ * debian/changelog kdissert and trang moved to Suggests, minor reordering
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 03 Sep 2007 23:14:43 +0100
+
+sisu (0.57.0-1) unstable; urgency=low
+
+ * new upstream, cleaning up output (as opposed to code), a minor syntax
+ addition, and change to sisurc.yml for search forms, see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 23 Aug 2007 01:30:10 +0100
+
+sisu (0.56.3-1) unstable; urgency=low
+
+ * new upstream, minor fixes, see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 19 Aug 2007 02:47:40 +0100
+
+sisu (0.56.2-1) unstable; urgency=medium
+
+ * new upstream, odf fix, see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 31 Jul 2007 21:16:20 +0100
+
+sisu (0.56.1-1) unstable; urgency=medium
+
+ * new upstream, minor refinement in a regex match, see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 31 Jul 2007 19:04:59 +0100
+
+sisu (0.56.0-1) unstable; urgency=medium
+
+ * same as 0.55.7, more significant version number used to flag (minor)
+ change to search db structure, (which may necessitate rebuild if used),
+ see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 31 Jul 2007 01:54:22 +0100
+
+sisu (0.55.7-1) unstable; urgency=medium
+
+ * new upstream, minor adjustments, some such as increase of auto-generated
+ identifier db field size verge on fixes, also addition of semi-colon as
+ possible url terminator, see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 31 Jul 2007 00:04:10 +0100
+
+sisu (0.55.6-1) unstable; urgency=medium
+
+ * new upstream, see changelog, includes url match fix and refinements
+
+ * vim syntax and ftplugin files moved back to /usr/share/vim/addons
+
+ * debian/control added recommends vim-addon-manager
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 28 Jul 2007 14:20:12 +0100
+
+sisu (0.55.5-1) unstable; urgency=medium
+
+ * initialize output directory, fix (Closes: #434168)
+
+ * vim syntax and ftplugin files install moved to /usr/share/vim-scripts
+
+ * minor upstream changes see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 22 Jul 2007 11:17:32 +0100
+
+sisu (0.55.4-1) unstable; urgency=medium
+
+ * new upstream, minor fix, see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 20 Jul 2007 07:44:03 +0100
+
+sisu (0.55.3-1) unstable; urgency=medium
+
+ * new upstream, polishing, see changelog
+
+ * debian, renamed editor syntax file directory
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 14 Jul 2007 10:31:07 +0100
+
+sisu (0.55.2-1) unstable; urgency=medium
+
+ * new upstream, various small fixes and improvements, see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 07 Jul 2007 09:32:37 +0100
+
+sisu (0.55.1-1) unstable; urgency=low
+
+ * new upstream, reviewed and reposted, includes fixes to dal and odf, see
+ changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 02 Jul 2007 18:14:01 +0100
+
+sisu (0.55.0-1) unstable; urgency=low
+
+ * License change - GPL v3 or later
+
+ * make lib available to ruby 1.9
+
+ * New upstream including some fixes, see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 01 Jul 2007 11:41:09 +0100
+
+sisu (0.54.1-1) unstable; urgency=low
+
+ * new upstream, with fix in cgi-search related to match highlighting, see
+ upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 15 Jun 2007 12:59:25 +0100
+
+sisu (0.54.0-1) unstable; urgency=low
+
+ * new upstream, minor additions to syntax, extended indent levels, see
+ upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 14 Jun 2007 10:49:58 +0100
+
+sisu (0.53.0-1) unstable; urgency=low
+
+ * new upstream, housekeeping, see upstream changelog
+ * [OT, note] scm switched to git
+ * lib placed in v0 (instead of 0.53)
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 02 Jun 2007 11:29:59 +0100
+
+sisu (0.52.7-1) unstable; urgency=low
+
+ * new upstream, texpdf minor fix
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 17 May 2007 20:39:29 +0100
+
+sisu (0.52.6-1) unstable; urgency=low
+
+ * new upstream, minor fix
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 14 May 2007 00:14:33 +0100
+
+sisu (0.52.5-1) unstable; urgency=low
+
+ * dependencies updated (Closes: #419294) [thanks for report Martin Pitt]
+
+ * new upstream, minor changes related to setting of TCP/IP port to permit
+ the change of postgresql database version. (you may need to check the
+ postgresql port used and set it appropriately for your system, by setting
+ PGPORT or making sure sisurc.yml has the right value if the postgresql
+ default 5432 is not used). Postgresql database upgrades in debian that are
+ used by sisu should occur independently of sisu version.
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 10 May 2007 01:50:08 +0100
+
+sisu (0.52.4-1) unstable; urgency=low
+
+ * new upstream, see changelog
+
+ * debhelper >= 5
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 05 May 2007 10:51:18 +0100
+
+sisu (0.52.3-1) unstable; urgency=medium
+
+ * texpdf (LaTeX:pdf) utf-8 headers adjusted to work with new file magic
+ information (utf-8 markup file is assumed)
+
+ * debian/control, reverted postgresql dependencies to 0.52.1 until update of
+ ruby drivers to comply with suggestions in #419294
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 26 Apr 2007 02:42:55 +0100
+
+sisu (0.52.2-1) unstable; urgency=low
+
+ * debian/control, postgresql dependency update, (was intended to close
+ 419294) [thank you for report Martin Pitt]
+
+ * minor upstream adjustment todo with links to generated output in html, see
+ changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 21 Apr 2007 15:21:37 +0100
+
+sisu (0.52.1-1) unstable; urgency=low
+
+ * new upstream, minor, see changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 14 Apr 2007 17:56:19 +0100
+
+sisu (0.52.0-1) unstable; urgency=low
+
+ * new upstream, introduces:
+ * declared filetype identifier,
+ * a default action for 'sisu [recognised filename]'
+ * gpl3 draft 3 as document markup sample
+ and includes minor fixes, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 07 Apr 2007 05:44:03 +0100
+
+sisu (0.51.0-1) unstable; urgency=low
+
+ * new upstream, mostly refactoring, but include changes to skins (their
+ simplification) which results in the need to modify existing skins
+ accordingly.
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 31 Mar 2007 10:56:14 +0100
+
+sisu (0.50.4-1) unstable; urgency=low
+
+ * new upstream, fixes to sample generated search form (cgi)
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 24 Mar 2007 09:32:49 +0000
+
+sisu (0.50.3-1) unstable; urgency=low
+
+ * new upstream, minor fixes
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 17 Mar 2007 16:05:32 +0000
+
+sisu (0.50.2-1) unstable; urgency=low
+
+ * new upstream, many small changes, most significant to do with integration
+ of access to search features. Minor help updates. See upstream changelog
+
+ * debian control, minor update to package description
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 17 Mar 2007 01:28:01 +0000
+
+sisu (0.50.1-1) unstable; urgency=low
+
+ * new upstream, several minor adjustments, most notably indexes not built
+ (automatically) on postgresql text/content and endnote fields, (rely on
+ tsearch, suggest manual building of Gin index), see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 10 Mar 2007 00:56:59 +0000
+
+sisu (0.50.0-1) unstable; urgency=low
+
+ * new upstream, several modest changes, see upstream changelog
+
+ * yaml files renamed with .yml extension including sisurc.yml
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 6 Mar 2007 02:23:56 +0000
+
+sisu (0.49.2-1) unstable; urgency=low
+
+ * new upstream, minor adjustments, see version manifest
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 24 Feb 2007 10:44:54 +0000
+
+sisu (0.49.1-1) unstable; urgency=low
+
+ * new upstream, see version manifest
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 10 Feb 2007 10:36:45 +0000
+
+sisu (0.49.0-1) unstable; urgency=low
+
+ * 0.49 opened [see 0.48.8-10] merged 0.48.8-10 upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 26 Jan 2007 00:38:04 +0000
+
+sisu (0.48.12-1) unstable; urgency=low
+
+ * [see 0.48.8-8] merged 0.48.8-8 upstream (Etch freeze is at 0.48.8)
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 24 Jan 2007 22:47:02 +0000
+
+sisu (0.48.11-1) unstable; urgency=low
+
+ * [see 0.48.8-7] merged 0.48.8-7 upstream (Etch freeze is at 0.48.8)
+ originally built on Fri, 12 Jan 2007 23:23:07 +0000
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 24 Jan 2007 22:37:06 +0000
+
+sisu (0.48.10-1) unstable; urgency=low
+
+ * [see 0.48.8-6] merged 0.48.8-6 upstream (Etch freeze is at 0.48.8)
+ originally built on Mon, 8 Jan 2007 22:25:23 +0000
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 24 Jan 2007 22:28:07 +0000
+
+sisu (0.48.9-1) unstable; urgency=low
+
+ * [see 0.48.8-2] merged 0.48.8-2 upstream (Etch freeze is at 0.48.8)
+ originally built on Wed, 27 Dec 2006 15:02:13 +0000
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 24 Jan 2007 21:09:40 +0000
+
+sisu (0.48.8-11) unstable; urgency=medium
+
+ * build "stable"
+ (based on stable upstream release = = = 0.49.1-1)
+
+ * Debian release snapshot, uploaded by Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 16 Feb 2007 00:36:09 +0000
+
+sisu (0.48.8-10) unstable; urgency=medium
+
+ * xml and xhtml adjustment of regex match of urls for xlink
+
+ * Debian release snapshot, uploaded by Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 23 Jan 2007 01:34:20 +0000
+
+sisu (0.48.8-9) unstable; urgency=medium
+
+ * use ISO 639-2 for language codes (Closes: #407937)
+ and related changes to help and man pages
+
+ * removed Danish sample markup files, (which need to be renamed da instead of
+ dk following iso 639-2) to reduce the size of the inter-diff against the
+ package in testing
+
+ * sisupod fixes:
+ * safeguard against accidental zipping (making sisupod) of entire
+ document markup directory, requests confirmation of action
+ (Closes: #407932)
+ * sisupod initialisation (and generation) in new work directory,
+ issue fixed (Closes: #407943)
+
+ * xml and xhtml several adjustments with related css changes
+ (Closes: #407938)
+
+ * vim syntax highlighting, minor fix to catch an existing markup shortcut
+ (Closes: #407941)
+
+ * cosmetic fixes:
+ * html toc author line
+ * debian document samples, tex pdf page break instruction
+ adjusted/corrected
+
+ * Debian release snapshot, uploaded by Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 22 Jan 2007 17:33:43 +0000
+
+sisu (0.48.8-8) unstable; urgency=medium
+
+ * use ISO 639-2 for language codes, [best implement now]
+ (also results in renaming of some document samples)
+
+ * sisupod fixes:
+ * added safeguard against accidental zipping (making sisupod) of entire
+ document markup directory, requests confirmation
+ * sisupod initialisation (and generation) in new work directory, fixed
+
+ * xml and xhtml several adjustments with related css changes
+
+ * cosmetic fixes:
+ * html toc author line
+ * debian document samples, tex pdf page break instruction
+ adjusted/corrected
+
+ * Debian release snapshot, uploaded by Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 21 Jan 2007 04:35:06 +0000
+
+sisu (0.48.8-7) unstable; urgency=medium
+
+ * modifications to sample search form introduced in -4 break it, reverted
+ (to use of static path for cgi-bin)
+ (Closes: #406281, Closes: #406280) [same bug]
+
+ * debian/control removed suggests in sisu-sqlite and sisu-postgresql on
+ libdbd-sqlite and libdbd-pgsql respectively, as they are not present in
+ testing/Etch
+ (Closes: #406282, Closes: #406284)
+
+ * sisu html man page updated/regenerated (from man page)
+
+ * Debian Etch related fix (cleared by Marc 'HE' Brockschmidt), uploaded by
+ Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 10 Jan 2007 04:58:09 +0000
+
+sisu (0.48.8-6) unstable; urgency=medium
+
+ * sisu-pdf texlive dependency adjusted on feedback from Norbert Preining
+ (Closes: #402807)
+ <http://lists.debian.org/debian-tex-maint/2007/01/msg00034.html>
+ <http://lists.debian.org/debian-tex-maint/2007/01/msg00033.html>
+
+ * Debian Etch related fix (cleared by Marc 'HE' Brockschmidt), uploaded by
+ Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 3 Jan 2007 17:21:27 +0000
+
+sisu (0.48.8-5) unstable; urgency=medium
+
+ * sisu-pdf texlive dependencies shortened and free from use of metapackages
+ [this should close #402807]
+
+ * year rollover 2006 has become 2007, Happy New Year.
+
+ * Debian Etch related fixes uploaded by Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 2 Jan 2007 16:00:25 +0000
+
+sisu (0.48.8-4) unstable; urgency=medium
+
+ * cgi sample form related modifications (relatively minor but nice to have
+ sorted):
+ * cgi_pgsql and cgi_sqlite, dynamic path used instead (fixed path will
+ result in errors where the default path is not used).
+ * cgi_pgsql and cgi_sqlite, "documentation" tip for copying generated cgi
+ sample to cgi-bin directory, prevent accidental copying to a directory
+ instead of file. Dynamic path used.
+ * debian/control Recommends libfcgi-ruby1.8 moved to sisu-postgresql and
+ sisu-sqlite (only used in this context)
+
+ * Debian Etch related fixes uploaded by Daniel Baumann
+ [depends for sisu-pdf introduced in -3 questioned/challenged by 'HE'
+ rightly as it turns out]
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 31 Dec 2006 03:06:45 +0000
+
+sisu (0.48.8-3) unstable; urgency=medium
+
+ * sisu latex generated, usepackage url (improved placement of urls)
+
+ * debian control, sisu-pdf now depends on texlive alone, (alternative tetex
+ depends removed - reason: problem keeping both working!), take on board
+ suggestion by to rely on texlive Frank Küster if tetex is problematic (this
+ addresses, but does not close #402807 without further discussion, dropping
+ alternative tetex depends simplifies sisu-pdf (tex) related depends, and
+ makes it much more reliable (also see in changelog earlier feedback on
+ sisu-pdf depends from Norbert Preining url at 0.47.7-3) depends here drop
+ reliance on metapackages, (extra checks required as to determine whether
+ texlive depends list may be shortened, playing safe))
+
+ * debian/control sisu recommends libfcgi-ruby1.8
+ (previously 'suggested'', needed for sample search form)
+
+ * documentation/help minor addition on initially creating postgresql
+ database for use if necessary
+
+ * Debian Etch related fixes uploaded by Daniel Baumann
+ (followed in quick succession by minor build additions in -4)
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 30 Dec 2006 12:52:05 +0000
+
+sisu (0.48.8-2) unstable; urgency=medium
+
+ * LaTeX, bugfix - restores missing left column object/paragraph numbers
+ (missing curly (close) brace) [important, though marked as normal]
+ [bug introduced somewhere between 0.47 and 0.48] (closes: #403037)
+
+ * LaTeX use mathptmx.sty instead of "obsolete" times.sty (as suggested by
+ Frank Küster in Bug#402807)
+
+ * cgi-sample form, an arbitrary limit set for sql query results
+ (1000 better than none) Closes: #403042)
+
+ * defaults, update sisu default homepage to current, (mainly urls)
+ [documentation]
+
+ * css, addition to correspond with change to homepage
+
+ * debian control, adds mention of editors other than vim for which there is
+ some kind of syntax support, kate, kwrite, gedit, diakonos [documentation]
+
+ * [note] alternative install script (ruby) is automatically updated during
+ this build (using rant-0.5.8 instead of rant-0.5.6)
+
+ * [note] version.yaml date changes, automatically updated during build
+
+ * Debian Etch fixes (cleared by HE), uploaded by Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 14 Dec 2006 16:50:57 +0000
+
+sisu (0.48.8-1) unstable; urgency=medium
+
+ * new upstream,
+ * fix to visual tables, permitting inclusion of column information
+ (required for concurrently released sisu-markup-samples (1.0.4))
+ * document samples update to include Debian constitution v1.3
+
+ * Debian release snapshot, uploaded by Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 27 Nov 2006 15:48:35 +0000
+
+sisu (0.48.7-1) unstable; urgency=medium
+
+ * upstream fixes, related to:
+ - cgi html search form, multilingual documents, url mapping of results
+ - dcc, document content digest, multilingual, fixes related to translation
+ and metadata extraction
+ - other more minor detail, see version manifest
+
+ * Debian release snapshot, uploaded by Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 19 Nov 2006 00:36:32 +0000
+
+sisu (0.48.6-1) unstable; urgency=medium
+
+ * upstream fixes related to:
+ - html, doc (single text, scroll version) tables
+ - texpdf, bugfix for (asterisk marker type) footnotes in headings
+
+ * Debian release snapshot, uploaded by Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 11 Nov 2006 21:43:21 +0000
+
+sisu (0.48.5-1) unstable; urgency=medium
+
+ * upstream fixes, including sisupod create - file selection refinement
+
+ * man pages minor update
+
+ * Debian release snapshot, uploaded by Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 9 Nov 2006 19:04:27 +0000
+
+sisu (0.48.4-1) unstable; urgency=medium
+
+ * upstream fixes (texpdf:tables, plaintext, conversion:footnotes)
+
+ * Debian release snapshot, uploaded by Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 7 Nov 2006 00:52:52 +0000
+
+sisu (0.48.3-1) unstable; urgency=high
+
+ * one file omitted in sisu 0.48.2 fix, see comments there
+
+ * Debian release snapshot, uploaded by Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 31 Oct 2006 18:09:38 +0000
+
+sisu (0.48.2-1) unstable; urgency=high
+
+ * ruby-1.8.5-3 uploaded yesterday, detects and breaks on cyclic include
+ errors which were found at a basic level of operation, rendering program
+ effectively broken. New ruby build affects all previous versions of sisu.
+ [Further code review is necessary to ascertain that this does not occur
+ anywhere else within sisu code base] (necessary fixes should not affect
+ previous versions of ruby)
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 31 Oct 2006 14:26:44 +0000
+
+sisu (0.48.1-2) unstable; urgency=medium
+
+ * debian/control recommends hyperestraier put back (sisu and sisu-complete)
+
+ * Debian release snapshot, uploaded by Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 30 Oct 2006 01:16:50 +0000
+
+sisu (0.48.1-1) unstable; urgency=medium
+
+ * debian/control removed recommends/suggests on hyperestraier, rename and
+ pgaccess as cause issues
+
+ * processing path, _sisu_processing, defaults to home or /tmp
+
+ * issue dealt with, when requested image not found
+
+ * Debian release snapshot, uploaded by Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 29 Oct 2006 17:06:05 +0000
+
+sisu (0.48.0-1) unstable; urgency=low
+
+ * etch release candidate, extra testing, numerous small fixes, (several
+ related to method renaming in sisu-0.47.7, also checks against both ruby
+ 1.8.5 and current 1.9, and as specified in upstream version manifest)
+
+ * new upstream introduces sisupod that sisu processing instructions can be
+ run against directly
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 28 Oct 2006 17:17:03 +0100
+
+sisu (0.47.8-1) unstable; urgency=low
+
+ * upstream contains minor fix, see version manifest
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 20 Oct 2006 00:12:52 +0100
+
+sisu (0.47.7-3) unstable; urgency=low
+
+ * debian/control sisu-pdf depends for tetex | texlive sorted,
+ feedback from Norbert Preining
+ http://lists.debian.org/debian-tex-maint/2006/10/msg00620.html
+
+ * Debian release snapshot, uploaded by Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 16 Oct 2006 19:26:28 +0100
+
+sisu (0.47.7-2) unstable; urgency=low
+
+ * sisu-pdf meta-package repackaged to work only with tetex,
+ alternative use of texlive meta-package dependency removed,
+ in its place a note that sisu will produce pdfs with the
+ texlive meta-package installed.
+ (May at later stage break package up into sisu-pdf-tetex
+ and sisu-pdf-texlive).
+
+ * Debian release snapshot, uploaded by Daniel Baumann
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 15 Oct 2006 17:38:20 +0100
+
+sisu (0.47.7-1) unstable; urgency=low
+
+ * sisu-pdf tetex|texlive installation depends
+
+ * new upstream, see version manifest
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 14 Oct 2006 12:50:20 +0100
+
+sisu (0.47.6-1) unstable; urgency=low
+
+ * new upstream, fixes to latex/pdf output, and a syntax extension
+ see version manifest
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 7 Oct 2006 15:43:41 +0100
+
+sisu (0.47.5-1) unstable; urgency=low
+
+ * fix a break caused by change of library name in 0.47.4
+ (that was not propagated into vc), related to creation of sisupod
+ (zipped markup with images etc.)
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 1 Oct 2006 17:16:24 +0100
+
+sisu (0.47.4-1) unstable; urgency=low
+
+ * minor upstream change (syntax highlighting), see version manifest
+
+ * debian policy violating firefox logo/image removed
+ (along with other browser related images) (Closes: #389500)
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 29 Sep 2006 01:31:04 +0100
+
+sisu (0.47.3-1) unstable; urgency=low
+
+ * new upstream, minor code review
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 23 Sep 2006 10:21:55 +0100
+
+sisu (0.47.2-1) unstable; urgency=low
+
+ * new upstream, minor fix required for ruby-1.8.5
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 22 Sep 2006 01:45:17 +0100
+
+sisu (0.47.1-1) unstable; urgency=low
+
+ * new upstream, fixes, see version manifest
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 18 Sep 2006 23:18:41 +0100
+
+sisu (0.47.0-1) unstable; urgency=low
+
+ * new upstream, some fixes see version manifest changelog
+
+ * debian/control depends zip and unzip added
+ used for sisupod.zip and ODF output
+
+ * odt.zip file replaces odt.tgz for ODF base file
+ found in data/sisu/odf i.e. /usr/share/sisu/odf
+ easy way to keep keep directory structure
+ (version control issue, hg drops empty directories)
+ odf uses zip compression anyway
+
+ * sisupod, (prepared sisu markup document) now uses zip compression and
+ file extension .zip (interoperability)
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 17 Sep 2006 16:43:15 +0100
+
+sisu (0.46.5-1) unstable; urgency=low
+
+ * new upstream, minor, update to documentation
+
+ * debian/control Priority at "optional"
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 9 Sep 2006 21:58:28 +0100
+
+sisu (0.46.4-1) unstable; urgency=low
+
+ * new upstream, minor
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 6 Sep 2006 03:03:39 +0100
+
+sisu (0.46.3-1) unstable; urgency=low
+
+ * debian/control moved from extra to optional -
+ does not conflict with anything, though a bit specialised perhaps
+
+ * debian/copyright, year 2006 added
+
+ * new upstream, see version manifest
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 4 Sep 2006 23:19:48 +0100
+
+sisu (0.46.2-1) unstable; urgency=low
+
+ * new upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 25 Aug 2006 22:38:44 +0100
+
+sisu (0.46.1-1) unstable; urgency=low
+
+ * new upstream
+
+ * debian/control conflicts with sisu-vim which existed prior to vim-sisu
+ both of which are removed
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 16 Aug 2006 21:08:47 +0100
+
+sisu (0.46.0-1) unstable; urgency=low
+
+ * new upstream, (0.44 branch with newer code reinstated) see version manifest
+
+ * debian/rules, repeated dh_compress removed
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 12 Aug 2006 03:27:09 +0100
+
+sisu (0.45.0-1) unstable; urgency=low
+
+ * new upstream, reversion to older 0.43 code as 0.44 LaTeX generation does
+ not play well yet with new code base
+
+ * debian changes introduced in 0.44 retained
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 7 Aug 2006 05:49:44 +0100
+
+sisu (0.44.0-1) unstable; urgency=low
+
+ * new upstream, see version manifest changelog
+
+ * debian/rules simplified
+
+ * debian/control sisu-pdf Depends changed
+
+ * debian/lintian/sisu added lintian override for man page and non-executables
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 6 Aug 2006 18:19:06 +0100
+
+sisu (0.43.0-1) unstable; urgency=low
+
+ * new upstream, new endnote sequences,
+ see version manifest
+
+ * debian vim/addons/syntax/sisu.vim add the new syntax file
+ (submit changes to Bram)
+
+ * simple xml modeling files copied to directory
+ /usr/share/doc/sisu/model/relaxng
+
+ * closing request for better package description
+ 0.42.2 (Closes: #377208)
+
+ * man pages for meta-packages moved to man(7)
+ 0.42.4 (Closes: #377209)
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 22 Jul 2006 02:33:41 +0100
+
+sisu (0.42.4-1) unstable; urgency=low
+
+ * minor touch upstream
+
+ * debian/control in addition to existing Replaces:
+ added Conflicts: vim-sisu, sisu-remote
+
+ * man pages for meta-packages moved to man(7)
+ (#377209)
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 17 Jul 2006 01:46:24 +0100
+
+sisu (0.42.3-1) unstable; urgency=low
+
+ * new upstream, fix, no require ruby dbi unless dbi action requested
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 11 Jul 2006 22:34:30 +0100
+
+sisu (0.42.2-1) unstable; urgency=low
+
+ * debian/control, removed sisu-remote, added recommends rsync,
+ openssh-client|lsh-client, keychain, to main sisu package
+ instead
+ (Closes: #377206)
+
+ * debian/control, removed vim-sisu, this used to contain syntax
+ highligter and color scheme now included in Vim 7, all that
+ remains is ftplugin, now installed by main sisu package
+ (Closes: #377207)
+
+ * debian/control, sisu Replaces: vim-sisu
+ debian/sisu.install installs ftplugin originally in vim-sisu
+
+ * debian/manpages, sisu (main package) now installs vim_sisu page
+ in man(7)
+ (Closes: #377209) [this was re-opened]
+
+ * debian/control, package description related issues:
+ * modified sisu
+ * modified sisu-complete
+ * modified sisu-postgresql
+ * modified sisu-sqlite
+ * modified sisu-pdf
+ * removed sisu-remote, (as sisu-remote is no more)
+ * removed vim-sisu, (as vim-sisu is no more)
+ * removed sisu-remote, (as sisu-remote is no more)
+ [consider adding a note on remote placement of documents in
+ sisu(8) later]
+ (#377208 verify that descriptions are satisfactory before closing)
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 8 Jul 2006 01:54:54 +0100
+
+sisu (0.42.1-1) unstable; urgency=low
+
+ * debian/control, removed recommends libtidy [non-existent, see
+ current libtidy-0.99-0, called in by tidy which is recommended
+ and sets libtidy dependency] (Closes: #377086)
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 6 Jul 2006 20:48:18 +0100
+
+sisu (0.42.0-2) unstable; urgency=low
+
+ * back to: control ruby >= 1.8.2
+ (upgrade complains about 1.8.4 availability - though installed)
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 6 Jul 2006 02:30:08 +0100
+
+sisu (0.42.0-1) unstable; urgency=low
+
+ * control ruby >= 1.8.4
+ (no testing done on ruby 1.8.2
+ and a report indicates there may be a problem)
+
+ * control to sisu-pdf added Depends: texlive-latex-extra
+ (for use of asterisk markers in endnotes...
+ used in U.S. law scholarly writings)
+
+ * vim-sisu package description changed (Closes: #374873)
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 6 Jul 2006 01:17:01 +0100
+
+sisu (0.41.8-1) unstable; urgency=low
+
+ * new upstream, minor feature enhancement, see version manifest
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 24 Jun 2006 20:49:53 +0100
+
+sisu (0.41.7-1) unstable; urgency=low
+
+ * Debian control, response to improved package description
+ request 'Home page' corrected to 'Homepage:' and vim folds
+ described in greater detail. Some detail added and
+ correction of name of package sisu-markup-samples
+ (provided in non-free)
+
+ * Debian rules, .ssm and .ssi files added to list of not
+ compressed file types (/usr/share/doc/sisu)
+
+ * Document samples "GPL2" and "Free as in Freedom" texts and
+ associated images included with package
+ (moved back from non-free sisu-markup-samples)
+ [FaiF is published under the GNU Free Documentation License,
+ without invariant sections]
+
+ * includes bugfix (for segmented html endnotes),
+ see version manifest
+
+ * includes minor feature enhancements, and first pass at proposed
+ alternative object model for sisu input (and metaverse),
+ see version manifest
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 24 Jun 2006 16:52:43 +0100
+
+sisu (0.41.6-1) unstable; urgency=low
+
+ * new upstream, integration and fixes to the addition in 0.41.4,
+ see version manifest
+
+ * debian control, recommends kdissert added
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 20 Jun 2006 01:20:13 +0100
+
+sisu (0.41.5-1) unstable; urgency=low
+
+ * new upstream, fix to minor addition in 0.41.4 see version manifest
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 19 Jun 2006 02:37:13 +0100
+
+sisu (0.41.4-1) unstable; urgency=low
+
+ * new upstream, minor addition, see version manifest
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 18 Jun 2006 02:07:47 +0100
+
+sisu (0.41.3-2) unstable; urgency=low
+
+ * /usr/share/doc/sisu for the time being do not compress
+ .sst or .rb files
+
+ * debian/dirs removed reference to usr/sbin as not used
+
+ * debian/rules minor cleaning of some commented out lines
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 15 Jun 2006 01:59:08 +0100
+
+sisu (0.41.3-1) unstable; urgency=low
+
+ * new upstream, small adjustments and fixes, see version manifest
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 14 Jun 2006 01:17:53 +0100
+
+sisu (0.41.2-1) unstable; urgency=low
+
+ * new upstream includes fixes, see version manifest
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 9 Jun 2006 07:23:31 +0100
+
+sisu (0.41.1-1) unstable; urgency=low
+
+ * new upstream, some fixes, see version manifest
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 7 Jun 2006 13:11:30 +0100
+
+sisu (0.41.0-1) unstable; urgency=low
+
+ * new upstream, many changes (primarily program internals),
+ see version manifest
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 3 Jun 2006 17:25:46 +0100
+
+sisu (0.40.4-1) unstable; urgency=low
+
+ * new upstream, minor changes tex pdf related
+
+ * source package directory name convention changed
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 28 May 2006 17:04:58 +0100
+
+sisu (0.40.3-1) unstable; urgency=low
+
+ * minor fixes, including (the (non-debian) rant/ruby make based)
+ installer
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 24 May 2006 23:32:58 +0100
+
+sisu (0.40.2-1) unstable; urgency=low
+
+ * new upstream, minor update, greater use of translation module
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 24 May 2006 05:31:34 +0100
+
+sisu (0.40.1-1) unstable; urgency=low
+
+ * [changed local apt archiver to reprepro]
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 22 May 2006 15:34:00 +0100
+
+sisu (0.40.0-1) unstable; urgency=low
+
+ * sisu-examples, markup book samples removed as not compliant with dfsg
+ document substantive content have the original author or publisher's
+ license... sisu-markup-samples now exists as a package in non-free
+
+ * a module for translations added
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 22 May 2006 04:03:27 +0100
+
+sisu (0.39.3-1) unstable; urgency=low
+
+ * new upstream, minor fix
+
+ * Debian release snapshot, uploaded by Wookey (at Debconf6)
+ [queue new: see 0.39.2 renaming of included packages]
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 14 May 2006 05:39:46 +0100
+
+sisu (0.39.2-2) unstable; urgency=low
+
+ * debian package fixes, control states vim-sisu replaces sisu-vim,
+ and path for ftplugins corrected
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 13 May 2006 07:30:32 +0100
+
+sisu (0.39.2-1) unstable; urgency=low
+
+ * debian policy standards version 3.7.2
+
+ * debian vim policy changes, rename sisu_vim vim_sisu
+ vim 7 in debian includes filetypes, syntax, and color, removed
+ vim-sisu includes ftplugin
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 13 May 2006 03:28:28 +0100
+
+sisu (0.39.1-1) unstable; urgency=low
+
+ * repair for digests/dcc which provide image checksums once more
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 8 May 2006 19:00:51 +0100
+
+sisu (0.39.0-1) unstable; urgency=low
+
+ * new upstream, changes to naming of html segments where automatic
+
+ * (back to) using Debian Policy Standards Version 3.7.0, Lintian and
+ Linda do not appear to have caught up with the version on my box,
+ or the suggestion that 3.7.2 be used
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 8 May 2006 01:32:16 +0100
+
+sisu (0.38.10-2) unstable; urgency=low
+
+ * rebuilt using new debian policy, Standards-Version 3.7.2
+ (previous build 0.38.10-1, used 3.7.0)
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 5 May 2006 03:00:42 +0100
+
+sisu (0.38.10-1) unstable; urgency=low
+
+ * new upstream, minor fixes
+
+ * Debian release
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 4 May 2006 01:08:47 +0100
+
+sisu (0.38.9-1) unstable; urgency=low
+
+ * new upstream, with adjustments, see version manifest,
+ in debian package: 'recommends' placed on hyperestraier;
+ debian/control updated Standards, 3.7.0
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 3 May 2006 04:41:38 +0100
+
+sisu (0.38.8-1) unstable; urgency=low
+
+ * new upstream, a few small fixes
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 29 Apr 2006 17:58:20 +0100
+
+sisu (0.38.7-1) unstable; urgency=low
+
+ * new upstream, code re-arrangement, minor,
+ code moved out of /usr/bin
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 27 Apr 2006 20:22:33 +0100
+
+sisu (0.38.6-1) unstable; urgency=low
+
+ * new upstream, first look at ruby 1.9
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 25 Apr 2006 22:40:24 +0100
+
+sisu (0.38.5-1) unstable; urgency=low
+
+ * primarily a rebuild, lintian 1.23.17 ("published" yesterday)
+ complains about existing sisu builds
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 23 Apr 2006 02:33:08 +0100
+
+sisu (0.38.4-1) unstable; urgency=low
+
+ * new upstream, a fix in markup version checking, and some
+ minor refinements, see version_manifest
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 21 Apr 2006 20:23:31 +0100
+
+sisu (0.38.3-1) unstable; urgency=low
+
+ * new upstream, minor refinement for conversions between
+ 0.37 and 0.38 markup
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 20 Apr 2006 02:29:10 +0100
+
+sisu (0.38.2-1) unstable; urgency=low
+
+ * new upstream, minor adjustments
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 19 Apr 2006 01:53:46 +0100
+
+sisu (0.38.1-1) unstable; urgency=low
+
+ * new upstream, minor fixes, a converter between 0.37 and 0.38
+ experimental markup (0.37 is substantially the same as 0.16,
+ the filenaming convention was changed)
+ see version manifest
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 17 Apr 2006 19:10:15 +0100
+
+sisu (0.38.0-1) unstable; urgency=low
+
+ * new upstream, several small additions, introduces alternative headers,
+ alternative experimental structural markup, and other little things,
+ see version_manifest
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 16 Apr 2006 02:24:17 +0100
+
+sisu (0.37.12-1) unstable; urgency=low
+
+ * new upstream, minor, vim syntax
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 9 Apr 2006 18:07:12 +0100
+
+sisu (0.37.11-1) unstable; urgency=low
+
+ * new upstream, minor, mostly vim syntax related
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 9 Apr 2006 00:05:42 +0100
+
+sisu (0.37.10-1) unstable; urgency=low
+
+ * new upstream, small things vim related
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 6 Apr 2006 23:19:27 +0100
+
+sisu (0.37.9-1) unstable; urgency=low
+
+ * new upstream, some attention to vim syntax and ftplugin
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 1 Apr 2006 14:39:13 +0100
+
+sisu (0.37.8-1) unstable; urgency=low
+
+ * new upstream, minor adjustments,
+ (ansi screen color default now off) see version_manifest
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 25 Mar 2006 15:38:39 +0000
+
+sisu (0.37.7-1) unstable; urgency=low
+
+ * new upstream, single fix
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 23 Mar 2006 23:19:10 +0000
+
+sisu (0.37.6-1) unstable; urgency=low
+
+ * new upstream, minor touches
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 23 Mar 2006 00:28:12 +0000
+
+sisu (0.37.5-1) unstable; urgency=low
+
+ * new upstream, several small changes, see version_manifest
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 22 Mar 2006 01:47:32 +0000
+
+sisu (0.37.4-1) unstable; urgency=low
+
+ * new upstream, minor fixes (in some html pages generated)
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 9 Mar 2006 18:59:34 +0000
+
+sisu (0.37.3-1) unstable; urgency=low
+
+ * new upstream, minor adjustment (default home page)
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 9 Mar 2006 01:29:51 +0000
+
+sisu (0.37.2-1) unstable; urgency=low
+
+ * reduced number of file extensions used in the .ss space
+ .sst .ssm .ssi (& .ssd), temp/secondary files get ._sst & .-sst
+ sst == sisu structured text [.s1 .s2 .s3],
+ ssm == sisu structured master [.r1 .r2 .r3],
+ ssi == sisu structured insert/information [.si],
+ _sst == secondary file [.t1 .t2 .t3],
+ -sst == downloaded sst (url) [.u1, .u2 .u3],
+ ssd == sisu structured document, sisudoc.tgz
+ See version manifest.
+
+ rename 's/\.s[123]$/\.sst/' *.s{1,2,3}
+ rename 's/\.r[123]$/\.ssm/' *.r{1,2,3}
+ rename 's/\.si$/\.ssi/' *.si
+
+ * edited sisu description in debian control file.
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 7 Mar 2006 22:39:51 +0000
+
+sisu (0.37.1-1) unstable; urgency=low
+
+ * new upstream, minor update in sisu-examples.
+ edited sisu description in debian control file.
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 6 Mar 2006 23:57:16 +0000
+
+sisu (0.37.0-1) unstable; urgency=low
+
+ * new upstream, new filename extensions,
+ using .ss extensions with a third identifying character:
+ .sst .ssf .ssm .ssc .ssi .ssu .sss .ssd
+ sst == sisu structured text, ssf == sisu structured file,
+ ssm == sisu structured master, ssc == sisu structured composite,
+ ssi == sisu structured insert/information,
+ ssu == downloaded sst (url),
+ sss == secondary file,
+ ssd == sisu structured document.
+ See version manifest.
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 5 Mar 2006 23:26:44 +0000
+
+sisu (0.36.25-1) unstable; urgency=low
+
+ * new upstream, minor changes
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 5 Mar 2006 11:52:25 +0000
+
+sisu (0.36.24-1) unstable; urgency=low
+
+ * new upstream, minor fixes,
+ also a fix and cross-linking in debian sample markup documents
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 28 Feb 2006 18:54:38 +0000
+
+sisu (0.36.23-1) unstable; urgency=low
+
+ * new upstream, several small fixes
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 27 Feb 2006 00:19:09 +0000
+
+sisu (0.36.22-1) unstable; urgency=low
+
+ * new upstream, minor fix, (odf endnote url matching)
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 23 Feb 2006 19:20:22 +0000
+
+sisu (0.36.21-1) unstable; urgency=low
+
+ * new upstream, small fixes, metaverse auto-numbering
+ headings/titles rules& html nav band, minor
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 22 Feb 2006 21:40:01 +0000
+
+sisu (0.36.20-1) unstable; urgency=low
+
+ * fix issue introduced by previous release, minor
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 22 Feb 2006 02:49:11 +0000
+
+sisu (0.36.19-1) unstable; urgency=low
+
+ * new upstream, a minor intermediate processing rule change,
+ and minor fixes (see version_manifest)
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 22 Feb 2006 01:08:37 +0000
+
+sisu (0.36.18-1) unstable; urgency=low
+
+ * new upstream, minor (cgi search form samples)
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 20 Feb 2006 02:11:54 +0000
+
+sisu (0.36.17-1) unstable; urgency=low
+
+ * new upstream, minor
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 19 Feb 2006 15:40:52 +0000
+
+sisu (0.36.16-1) unstable; urgency=low
+
+ * new upstream, minor (cgi search form related, see manifest)
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 19 Feb 2006 13:01:46 +0000
+
+sisu (0.36.15-1) unstable; urgency=low
+
+ * new upstream, minor
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 18 Feb 2006 17:05:55 +0000
+
+sisu (0.36.14-1) unstable; urgency=low
+
+ * new upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 18 Feb 2006 03:00:29 +0000
+
+sisu (0.36.13-1) unstable; urgency=low
+
+ * new upstream, minor fix
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 12 Feb 2006 23:16:05 +0000
+
+sisu (0.36.12-1) unstable; urgency=low
+
+ * new upstream, small fixes
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 9 Feb 2006 18:49:43 +0000
+
+sisu (0.36.11-1) unstable; urgency=low
+
+ * new upstream, minor
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 9 Feb 2006 05:20:07 +0000
+
+sisu (0.36.10-1) unstable; urgency=low
+
+ * new upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 8 Feb 2006 18:23:38 +0000
+
+sisu (0.36.9-1) unstable; urgency=low
+
+ * upstream with filelist fix, see version_manifest
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 7 Feb 2006 05:13:52 +0000
+
+sisu (0.36.8-1) unstable; urgency=low
+
+ * new upstream, little things noted in version_manifest
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 6 Feb 2006 21:29:10 +0000
+
+sisu (0.36.7-1) unstable; urgency=low
+
+ * new upstream, minor fixes
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 5 Feb 2006 21:47:36 +0000
+
+sisu (0.36.6-1) unstable; urgency=low
+
+ * new upstream, many fixes, see version_manifest
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 4 Feb 2006 13:43:30 +0000
+
+sisu (0.36.5-1) unstable; urgency=low
+
+ * proposed new build for Debian upload, built in manner described for
+ 0.36.4-2, (this would prevent the need to maintain two different
+ builds of the same package)
+ * fewer packages are created than in the rejected Debian upload
+ * it is much easier for the user to install the components they
+ need than in the current accpted build
+ * it is not necessary to install the likes of tetex, tetex-extra,
+ latex-ucs or postgresql and various drivers or sqlite etc. if you
+ are not going to use them
+ the three different builds are represented by
+ 0.36.4-1, 0.36.4-2, and 0.36.4-3, please see changelog notes below
+
+ * copyright file makes mention of setup.rb by Minero Aoki which is
+ included in the tarball, and licensed under the Gnu Lesser GPL
+
+ * copyright file makes mention of Rant which though not included generates
+ the install file included in the tarball (Rant is by Stephan Lang and
+ licensed under the Gnu Lesser GPL) [corrected erroneously referred to
+ the similar Rake]
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 6 Jan 2006 21:25:15 +0000
+
+sisu (0.36.4-3) unstable; urgency=low
+
+ * post 0.32.0 build style:
+ * sisu : basic build, no dependencies really beyond ruby
+ * sisu-pdf : dependencies for sisu to generate pdfs latex related
+ * sisu-postgresql : dependencies for sisu to populate a postgresql
+ database including postgresql itself and various ruby drivers
+ * sisu-remote : dependencies for remote placement of sisu output,
+ via ssh and rsync
+ * sisu-examples : markup and other examples in sisu, fairly large
+ * sisu-sqlite : dependencies for sisu to populate an sqlite
+ database including sqlite itself and various ruby drivers
+ * sisu-vim : vim syntax highlighting and folds only of interest
+ if vim/gvim is used
+ ** sisu-webrick : use of ruby webrick server with sisu
+ ** sisu-termsheet : a lesser used component, for producing output
+ by merging termsheets/forms against standard formm documents
+ ** sisu-texinfo : a lesser used component, for texinfo output
+ * sisu-complete : installing the whole of sisu and its component
+ parts
+ may end up using 0.36.4-2 which is proposed new build for Debian
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 1 Jan 2006 18:20:44 +0000
+
+sisu (0.36.4-2) unstable; urgency=low
+
+ * proposed new build for Debian, would become future default build
+ package is broken into components with different dependencies
+ corresponding to different possible uses of sisu, which only are
+ of interest if the functions in those components are to be used.
+ For example if pdfs are not required the dependency on tetex
+ including tetex-extra and latex-ucs is unecessarily large,
+ likewise if postgresql is not going to be used to have a
+ dependency on postgresql is unecessary.
+ On the other hand if pdfs are to be generated, there are a number
+ of dependencies beyond tetex that are required which can be
+ confusing, (and which have cased users grief in the past).
+ Likewise for either sql database supported in the default install
+ the dependencies to get them working is not straightforward.
+ In this build specifying sisu-pdf will result in the dependencies
+ for producing pdfs being loaded and sisu-postgresql the necessary
+ dependencies for that (both large additions if not already
+ installed or required). Individual components in this build are:
+ * sisu : basic build, no dependencies really beyond ruby
+ * sisu-pdf : dependencies for sisu to generate pdfs latex related
+ * sisu-postgresql : dependencies for sisu to populate a postgresql
+ database including postgresql itself and various ruby drivers
+ * sisu-remote : dependencies for remote placement of sisu output,
+ via ssh and rsync
+ * sisu-examples : markup and other examples in sisu, fairly large
+ * sisu-sqlite : dependencies for sisu to populate an sqlite
+ database including sqlite itself and various ruby drivers
+ * sisu-vim : vim syntax highlighting and folds only of interest
+ if vim/gvim is used
+ * sisu-complete : installing the whole of sisu and its component
+ parts
+ [it is also much easier to keep track of which dependency and which
+ recommendation or suggestion belongs to which component]
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 1 Jan 2006 17:34:15 +0000
+
+sisu (0.36.4-1) unstable; urgency=low
+
+ * built old way for Debian upload (pre-0.31.5 style build.
+ post 0.32.0 packages are also available in smaller component
+ parts)
+ * sisu : basic build, no dependencies really beyond ruby,
+ all additional requirements for various components specified as
+ recommendations
+ * sisu-vim : vim syntax highlighting and folds only of interest
+ if vim/gvim is used
+ * sisu-examples : markup and other examples in sisu, fairly large
+
+ * Debian release snapshot (check), uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 1 Jan 2006 17:27:48 +0000
+
+sisu (0.36.3-1) unstable; urgency=low
+
+ * New upstream, fixes related to multi-language, and sysnv change to
+ initialization of constants
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 31 Dec 2005 15:07:18 +0000
+
+sisu (0.36.2-1) unstable; urgency=low
+
+ * New upstream, small fixes
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 30 Dec 2005 23:54:34 +0000
+
+sisu (0.36.1-1) unstable; urgency=low
+
+ * New upstream, minor fix
+ html batch processing output file placement
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 29 Dec 2005 23:22:47 +0000
+
+sisu (0.36.0-1) unstable; urgency=low
+
+ * New upstream, change to some default settings,
+ else minor refinements
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 29 Dec 2005 17:43:00 +0000
+
+sisu (0.35.0-1) unstable; urgency=low
+
+ * New upstream, multilingual document model
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 28 Dec 2005 01:32:32 +0000
+
+sisu (0.34.2-1) unstable; urgency=low
+
+ * New upstream: fix in css image path; digests added some doc info
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 19 Dec 2005 18:42:42 +0000
+
+sisu (0.34.1-1) unstable; urgency=low
+
+ * New upstream, small mostly cosmetic changes related to metaverse:
+ (html and wmap output); url correction (html output); md5s for
+ sourcefiles if shared
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 18 Dec 2005 23:00:16 +0000
+
+sisu (0.34.0-1) unstable; urgency=low
+
+ * New upstream: includes changes to directory structure for
+ configuration, of both
+ local markup directories, and
+ ouput/publishing directories
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 18 Dec 2005 00:34:32 +0000
+
+sisu (0.33.0-1) unstable; urgency=low
+
+ * New upstream, (some changes to processing paths)
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 15 Dec 2005 02:03:37 +0000
+
+sisu (0.32.5-1) unstable; urgency=low
+
+ * orig.tar.gz should now be updated together with debian package
+ orig.tar.gz has not been updated properly since 0.31.4, debian
+ package has issue with autopackage builder
+
+ * debian package improved, however: diffs started from scratch,
+ information/history abandoned
+ Reason: undetermined problem with (home brewed) automated package
+ builder. automated package builder (which uses darcs and
+ darcs-buildpackage) builds package normally/properly with a
+ pristine directory structure, but not with accumulated debian
+ build history.
+ For now, the orig.tar.gz and debian package structure are
+ updated, and debian history is not included.
+
+ * directory named extra removed from source tarball,
+ extra/debian/man moved to debian/man
+
+ * debian, correction of a man page
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 14 Dec 2005 05:39:43 +0000
+
+sisu (0.32.4-1) unstable; urgency=low
+
+ * New upstream (odf images, and document metadata)
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 13 Dec 2005 02:11:01 +0000
+
+sisu (0.32.3-1) unstable; urgency=low
+
+ * New upstream, (includes minor re-fix to html endnote urls)
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 11 Dec 2005 13:52:15 +0000
+
+sisu (0.32.2-1) unstable; urgency=low
+
+ * Upstream sqlite repair
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 8 Dec 2005 18:54:18 +0000
+
+sisu (0.32.1-1) unstable; urgency=low
+
+ * Debian control, comma added to comma delimited depends list for
+ sisu_complete
+
+ * Minor cleaning of upstream, and a file dropped (hmtl_css)
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 3 Dec 2005 21:52:59 +0000
+
+sisu (0.32.0-1) unstable; urgency=low
+
+ * New upstream, minor changes
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 1 Dec 2005 23:33:20 +0000
+
+sisu (0.31.5-1) unstable; urgency=low
+
+ * New upstream
+
+ * Debian package, complete replaces composite, remote introduced
+ directory structure changed extra/debian instead of man.deb
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 1 Dec 2005 19:20:14 +0000
+
+sisu (0.31.4-1) unstable; urgency=low
+
+ * Debian packages broken down, for better control over dependencies
+ several smaller packages, source package structure affected
+ (control, .install, .manpages)
+
+ * sisu-composite together with sisu-examples installs all sisu
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 29 Nov 2005 05:32:29 +0000
+
+sisu (0.31.3-2) unstable; urgency=low
+
+ * debian:control Depends: ruby (>=1.8.2)
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 28 Nov 2005 20:17:53 +0000
+
+sisu (0.31.3-1) unstable; urgency=low
+
+ * New upstream, control file:
+ ruby depends made 1.8.3
+ checked with pbuilder, misc:Depends removed
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 28 Nov 2005 03:55:19 +0000
+
+sisu (0.31.2-1) unstable; urgency=low
+
+ * debian autobuilding fix to external scaffolding
+ [package has same contents as 0.31.1]
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 26 Nov 2005 17:46:55 +0000
+
+sisu (0.31.1-1) unstable; urgency=low
+
+ * New upstream, minor fixes
+ [Note: change to automated debian build procedure]
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 26 Nov 2005 15:20:47 +0000
+
+sisu (0.31.0-1) unstable; urgency=low
+
+ * New upstream following 0.30.9 path
+ for header regex: italics & bold (0.30.10 follows 0.30.8)
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 25 Nov 2005 23:32:54 +0000
+
+sisu (0.30.10-1) unstable; urgency=low
+
+ * New upstream, rollback in behavior to 0.30.8 header matching for
+ bold and italics (comma delimited list), 0.30.9 changes now mapped
+ to version 0.31
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 25 Nov 2005 22:55:37 +0000
+
+sisu (0.30.9-1) unstable; urgency=low
+
+ * New upstream, adjustment to package unpack directory structure
+ to match new setup.rb default man directory moved from data/man
+ (install directory structure should remain the same)
+ Minero Aoki's setup.rb included as an alterantive installer
+ for source package
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 23 Nov 2005 00:25:04 +0000
+
+sisu (0.30.8-1) unstable; urgency=low
+
+ * New upstream, LaTeX related, use of pdflatex,
+ and pdfetex with pdflatex parameters (Debian specific)
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 22 Nov 2005 01:25:58 +0000
+
+sisu (0.30.7-1) unstable; urgency=low
+
+ * New upstream, composite document fix, manual closure of file
+ otherwise minor
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 21 Nov 2005 01:23:49 +0000
+
+sisu (0.30.6-1) unstable; urgency=low
+
+ * New upstream, minor
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 20 Nov 2005 19:46:48 +0000
+
+sisu (0.30.5-1) unstable; urgency=low
+
+ * New upstream, minor fixes
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 20 Nov 2005 02:28:08 +0000
+
+sisu (0.30.4-1) unstable; urgency=low
+
+ * New upstream, minor fixes and a file renamed
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 19 Nov 2005 23:19:08 +0000
+
+sisu (0.30.3-1) unstable; urgency=low
+
+ * New upstream, markup dir ./_sisu/conf replaces ./_sisu/config
+ minor bugfix for pgsql (8.1)
+ control file sisu reorganised
+ debian control suggests keychain (added)
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 19 Nov 2005 01:25:34 +0000
+
+sisu (0.30.2-1) unstable; urgency=low
+
+ * New upstream, cleaning, minor
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 16 Nov 2005 00:26:57 +0000
+
+sisu (0.30.1-1) unstable; urgency=low
+
+ * New upstream, minor
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 14 Nov 2005 18:14:39 +0000
+
+sisu (0.30.0-1) unstable; urgency=low
+
+ * New upstream, metadata, third acronym fixed
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 13 Nov 2005 17:49:47 +0000
+
+sisu (0.29.5-1) unstable; urgency=low
+
+ * New upstream, retract latex to pdf changes for now
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 11 Nov 2005 07:47:51 +0000
+
+sisu (0.29.4-1) unstable; urgency=low
+
+ * New upstream, latex to pdf looks to use pdfetex, pdftex or pdflatex
+ (there has been some debian renaming),
+ opendocument.rb renamed odf.rb
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 11 Nov 2005 02:17:03 +0000
+
+sisu (0.29.3-1) unstable; urgency=low
+
+ * New upstream, new processing features, new processing flags,
+ plus some flags changed (is release candidate for 0.30.0)
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 9 Nov 2005 06:11:53 +0000
+
+sisu (0.29.2-1) unstable; urgency=low
+
+ * New upstream, new directory data/sisu created to remove creaping
+ dependency of sisu main package on sisu-examples for run time png
+ and odf files, necessary adjustment in debian/sisu.install
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 7 Nov 2005 07:55:59 +0000
+
+sisu (0.29.1-1) unstable; urgency=low
+
+ * New upstream, control adds suggests lv (file encoding conversions)
+ and rcs (as alternative to cvs, for document version number
+ tracking)
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 5 Nov 2005 17:16:36 +0000
+
+sisu (0.29.0-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 31 Oct 2005 18:22:28 +0000
+
+sisu (0.28.4-1) unstable; urgency=low
+
+ * New upstream, minor change to package description,
+ for other changes see version_manifest
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 31 Oct 2005 17:56:13 +0000
+
+sisu (0.28.3-1) unstable; urgency=low
+
+ * New upstream, touch
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 23 Oct 2005 00:28:44 +0100
+
+sisu (0.28.2-1) unstable; urgency=low
+
+ * New upstream, character encoding related, utf-8
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 22 Oct 2005 23:22:14 +0100
+
+sisu (0.28.1-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 22 Oct 2005 18:47:25 +0100
+
+sisu (0.28.0-1) unstable; urgency=low
+
+ * New upstream, Debian released ruby-1.8.3-2 which does not segfault
+ sisu, this version number increse obsoletes emergency sisu-0.27.0
+ build, that was made available, as workaround to ruby segfault
+ problem
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 21 Oct 2005 02:40:25 +0100
+
+sisu (0.26.4-1) unstable; urgency=low
+
+ * New upstream, (a) control recommend added sqlite, previously
+ overlooked; (b) recommend zip added used in making of open
+ document (c) recommend removed incorrect libcgi_ruby
+ (libfcgi-ruby1.8 remains) (d) added basic open document file
+ structure as a .tgz file
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 18 Oct 2005 03:09:12 +0100
+
+sisu (0.26.3-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 7 Oct 2005 02:16:59 +0100
+
+sisu (0.26.2-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 30 Sep 2005 20:51:19 +0100
+
+sisu (0.26.1-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 18 Sep 2005 23:36:17 +0100
+
+sisu (0.26.0-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 18 Sep 2005 12:21:55 +0100
+
+sisu (0.25.11-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 17 Sep 2005 01:53:12 +0100
+
+sisu (0.25.10-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 16 Sep 2005 00:01:49 +0100
+
+sisu (0.25.9-1) unstable; urgency=low
+
+ * New upstream
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 14 Sep 2005 18:30:27 +0100
+
+sisu (0.25.8-1) unstable; urgency=low
+
+ * New upstream, pinfo added to suggests
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 14 Sep 2005 01:41:04 +0100
+
+sisu (0.25.7-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 13 Sep 2005 07:04:45 +0100
+
+sisu (0.25.6-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 12 Sep 2005 19:00:04 +0100
+
+sisu (0.25.5-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 12 Sep 2005 05:14:48 +0100
+
+sisu (0.25.4-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 12 Sep 2005 04:37:36 +0100
+
+sisu (0.25.3-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 12 Sep 2005 03:01:02 +0100
+
+sisu (0.25.2-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 10 Sep 2005 21:37:18 +0100
+
+sisu (0.25.1-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 10 Sep 2005 19:33:04 +0100
+
+sisu (0.25.0-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 10 Sep 2005 16:11:25 +0100
+
+sisu (0.24.2-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 9 Sep 2005 18:23:08 +0100
+
+sisu (0.24.1-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 8 Sep 2005 22:08:45 +0100
+
+sisu (0.24.0-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 7 Sep 2005 18:55:34 +0100
+
+sisu (0.23.1-1) unstable; urgency=low
+
+ * New upstream, cgi (naive) search form generator added to lib
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 7 Sep 2005 01:33:34 +0100
+
+sisu (0.23.0-1) unstable; urgency=low
+
+ * New upstream, input files changed to use utf-8 or iso8859,
+ new recommends: latex-ucs (required if generating pdf) and
+ librmagick-ruby
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 6 Sep 2005 02:11:55 +0100
+
+sisu (0.22.1-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 1 Sep 2005 02:51:35 +0100
+
+sisu (0.22.0-1) unstable; urgency=low
+
+ * New upstream:
+ Recommends rmagick (ruby imagemagick library),
+ FSF address updated.
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 31 Aug 2005 02:15:38 +0100
+
+sisu (0.21.2-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 28 Aug 2005 19:43:15 +0100
+
+sisu (0.21.1-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 28 Aug 2005 16:04:55 +0100
+
+sisu (0.21.0-1) unstable; urgency=low
+
+ * New upstream, some changes to directory structure
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 28 Aug 2005 00:34:37 +0100
+
+sisu (0.20.9-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 26 Aug 2005 01:08:38 +0100
+
+sisu (0.20.8-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 25 Aug 2005 02:08:18 +0100
+
+sisu (0.20.7-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 24 Aug 2005 17:45:22 +0100
+
+sisu (0.20.6-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 22 Aug 2005 21:00:25 +0100
+
+sisu (0.20.5-1) unstable; urgency=low
+
+ * New upstream
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 19 Aug 2005 15:54:26 +0100
+
+sisu (0.20.4-1) unstable; urgency=low
+
+ * New upstram. Removed ruby-libyaml (a bit of a story why it is there
+ in the first place, as is not required for ruby >=1.8 i.e. the
+ versions of ruby that sisu is written for)
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 18 Aug 2005 23:17:26 +0100
+
+sisu (0.20.3-1) unstable; urgency=low
+
+ * New upstream
+
+ * Debian release snapshot, uploaded by Wookey
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 14 Aug 2005 13:54:33 +0100
+
+sisu (0.20.2-1) unstable; urgency=low
+
+ * New upstream (from now) signed against ralph@amissah.com
+ (previous against ralph.amissah@gmail.com)
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 14 Aug 2005 03:11:10 +0100
+
+sisu (0.20.1-1) unstable; urgency=low
+
+ * signed dsc & changes files
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 12 Aug 2005 12:27:56 +0100
+
+sisu (0.20.0-2) unstable; urgency=low
+
+ * debian/control recommend postgresql (>=8.0.0). correction
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 11 Aug 2005 21:22:57 +0100
+
+sisu (0.20.0-1) unstable; urgency=low
+
+ * New upstream package, default database names changed
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 11 Aug 2005 20:36:01 +0100
+
+sisu (0.18.8-1) unstable; urgency=low
+
+ * New upstream package
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 10 Aug 2005 21:13:33 +0100
+
+sisu (0.18.7-1) unstable; urgency=low
+
+ * New upstream package: conflcting license note removed
+
+ * Debian release snapshot, uploaded by Joachim Breitner
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 9 Aug 2005 02:27:27 +0100
+
+sisu (0.18.6-1) unstable; urgency=low
+
+ * New upstream package
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 8 Aug 2005 12:44:06 +0100
+
+sisu (0.18.5-1) unstable; urgency=low
+
+ * New upstream package
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 7 Aug 2005 00:17:45 +0100
+
+sisu (0.18.4-1) unstable; urgency=low
+
+ * New upstream package
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 3 Aug 2005 11:00:05 +0100
+
+sisu (0.18.3-1) unstable; urgency=low
+
+ * New upstream package
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 26 Jul 2005 19:49:18 +0100
+
+sisu (0.18.2-1) unstable; urgency=low
+
+ * New upstream package
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 25 Jul 2005 19:16:30 +0100
+
+sisu (0.18.1-1) unstable; urgency=low
+
+ * New upstream package
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 24 Jul 2005 19:46:03 +0100
+
+sisu (0.18.0-1) unstable; urgency=low
+
+ * New upstream package: metaverse structure change, includes md5
+ digests of objects (paragraphs, tables, images, endnotes etc)
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 22 Jul 2005 11:41:30 +0100
+
+sisu (0.16.25-1) unstable; urgency=low
+
+ * change to markup for Free as in Freedom only
+
+ * Initial Debian release, uploaded by Gunnar Wolf (at Debconf5)
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 16 Jul 2005 21:15:32 +0100
+
+sisu (0.16.24-1) unstable; urgency=low
+
+ * copyright string made more clear as 1997, 1998, 1999, 2000, 2001, 2002,
+ 2003, 2004, 2005 ... only question being whether it should not have been
+ 1996.
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 12 Jul 2005 20:04:21 +0100
+
+sisu (0.16.23-1) unstable; urgency=low
+
+ * copyright headers changed within files for Debian
+
+ * some changes in use of ocn for segment naming in html output
+
+ * a couple of postgresql fileds changed to text
+
+ * cosmetic rearrangement of code
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 12 Jul 2005 18:47:31 +0100
+
+sisu (0.16.22-1) unstable; urgency=low
+
+ * metaverse fix for alternative endnote markup marker
+ at end of line~^
+
+ * texpdf fix for images, (where dimensions not
+ provided) not final, may need to pass through
+ imagemagick at metaverse stage
+
+ * fix to cgi sample sisu_search.cgi
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 7 Jul 2005 19:04:52 +0100
+
+sisu (0.16.21-1) unstable; urgency=low
+
+ * minor bugfix (param screen print)
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 3 Jul 2005 14:33:00 +0100
+
+sisu (0.16.20-1) unstable; urgency=low
+
+ * separated out sisu vim files (syntax & folds)
+
+ * touch to syntax highlighting
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 3 Jul 2005 12:56:13 +0100
+
+sisu (0.16.19-1) unstable; urgency=low
+
+ * small touches to vim syntax highlighting.
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 1 Jul 2005 18:37:44 +0100
+
+sisu (0.16.18-1) unstable; urgency=low
+
+ * some fixes to vim syntax highlighing: - changes to markup syntax
+ introduced in 0.16 release broke parts of syntax highlighter,
+ more no doubt to follow.
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 1 Jul 2005 02:35:13 +0100
+
+sisu (0.16.17-1) unstable; urgency=low
+
+ * separated color file out from ftplugin ... called dusk (or slate) by
+ me for several years i now call it sisu... perhaps i should stick
+ with slate as it is pretty appropriate... hmmm, slate
+
+ * NB there is an issue with debuild or darcs-buildpackage after tonight's
+ update, have fallen to an older installation, lintian check version
+ given is from a newer install, so gives a warning.
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 30 Jun 2005 01:03:25 +0100
+
+sisu (0.16.16-1) unstable; urgency=low
+
+ * small touches to offer vim config files working the way i am used to
+ with Debian install... needs testing by someone with different
+ habits though.
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 29 Jun 2005 21:39:55 +0100
+
+sisu (0.16.15-1) unstable; urgency=low
+
+ * separated vim syntax and ftplugin directory...
+ have still got color file in ftplugin/sisu.vim file
+ which is not acceptable
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 29 Jun 2005 18:17:16 +0100
+
+sisu (0.16.14-1) unstable; urgency=low
+
+ * sisu vim ftplugin ... for folds, syntax, colors, markup
+ auto installed in debian,
+ (but uses shared filetype in /usr/share/vim/addons
+ check how that is supposed to work)
+ else (non-debian install)
+ Rantfile places in /usr/share/sisu-examples/config/vim
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 29 Jun 2005 17:02:20 +0100
+
+sisu (0.16.13-1) unstable; urgency=low
+
+ * debian setup of vim syntax ok... however much vim setup still
+ to automate, immediately noticable: folds for sisu not sorted;
+ and permitting cursor movement up and down without following
+ long lines with screen wrap; (and no clever way yet to
+ contribute colors other than through sisu-examples, but
+ they being user preference should be contributed with care).
+
+ * on_markup.txt quick check & minor update
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 29 Jun 2005 06:01:38 +0100
+
+sisu (0.16.12-1) unstable; urgency=low
+
+ * home page index.html creation, path precedence set:
+ ~/.sisu/skin/doc
+ /etc/sisu/skin/doc
+ defaults
+ and content is interchangeable (so future latent break
+ is less likely)
+
+ * touch to Rantfile
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 27 Jun 2005 23:26:52 +0100
+
+sisu (0.16.11-1) unstable; urgency=low
+
+ * bugfix a default variable,
+ in defaults version should be @ver
+ quick fix, revist: currently index.html taken from
+ ~/.sisu/skin/doc if it exists else defaults,
+ /etc/sisu/skin/doc is ignored, breaking expected precedence
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 27 Jun 2005 18:09:13 +0100
+
+sisu (0.16.10-1) unstable; urgency=low
+
+ * small edits to man pages and help
+ NB have taken out reference to alternative markup possibilites
+ e.g. b{ for bold }b being available as well as
+ *{ bold text }* (as the letter the and html equivalents are
+ depreciated, having or using alternative markup styles is
+ less tidy)
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 26 Jun 2005 23:49:31 +0100
+
+sisu (0.16.9-1) unstable; urgency=low
+
+ * cleaning up of man pages, largely for html presentation
+ generated by rman
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 26 Jun 2005 03:10:51 +0100
+
+sisu (0.16.8-1) unstable; urgency=low
+
+ * minor edits
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 25 Jun 2005 17:45:12 +0100
+
+sisu (0.16.7-1) unstable; urgency=low
+
+ * added the man pages in html (converted to html using rman)
+ http://polyglotman.sourceforge.net/rman.html
+
+ * related rather cosmetic changes
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 25 Jun 2005 16:37:30 +0100
+
+sisu (0.16.6-1) unstable; urgency=low
+
+ * vim folds for sisu markup files updated command is :F (ruby folds :R)
+ assuming the file is in place and in use
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 25 Jun 2005 04:24:22 +0100
+
+sisu (0.16.5-1) unstable; urgency=low
+
+ * some cleaning of wordmap output, regex exclusions added, not elegant
+ (special issue pages include sha and md5 output, also excluded)
+
+ * [released 0.16.6:] vim folds for sisu markup files updated command
+ is :F (ruby folds :R) assuming the file is in place and in use
+
+ * comments, url locations of samples, output, etc. added to
+ markup syntax files (in addition to SiSU home which was already
+ there)
+
+ * removed from tarball markup samples eu contract
+ law principles can be found at
+ http://www.jus.uio.no/sisu/sample
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 24 Jun 2005 19:17:43 +0100
+
+sisu (0.16.4-1) unstable; urgency=low
+
+ * man 8 sisu post installation instructions looked at
+
+ * an image path adjusted
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 23 Jun 2005 06:08:38 +0100
+
+sisu (0.16.3-1) unstable; urgency=low
+
+ * tables fixed, much latent breakage sorted
+ * html segments fixed (scroll was ok)
+ * xml sax and dom sorted
+ * xml css naive but done
+ * latex/pdf done
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 23 Jun 2005 00:42:04 +0100
+
+sisu (0.16.2-1) unstable; urgency=low
+
+ * conditional heading reinstated /^[12~{ }~ \?\s/
+ (may be used when it is expected that a document may be
+ imported into another, and the controling documents level
+ 1 and/or 2 headings should be used instead (take precedence))
+
+ * rant install options, force specification of root if wish to
+ proceed as root, (previously was default on ok or continue)
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 22 Jun 2005 18:08:19 +0100
+
+sisu (0.16.1-1) unstable; urgency=low
+
+ * touches to documentation, markup related
+
+ * markup syntax table is out of date, reference to it removed
+ replaced by suggestion you see online markup sample directory
+ http://www.jus.uio.no/sisu/sample
+
+ * fix, one sample document was overlooked in last package
+ (autonomy_markup2)
+
+ * in ./debian/control updated lintian standards version number
+ to 3.6.2 from 3.6.1
+ (to get rid of lintian warning: out-of-date-standards-version)
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 22 Jun 2005 02:12:58 +0100
+
+sisu (0.16.0-1) unstable; urgency=low
+
+ * development branch folded back in to main,
+ plus a couple of touches
+ a bit early, testing now required in stable
+ WARNING Breaks Old Markup Syntax
+
+ Markup Syntax Cleaning - reduction in characters used
+ and the removal of several uses of unclosed curly brackets
+
+ Vim Regex Substitution Summary of Markup Syntax Changes:
+ :%s/\([0-6]\){\~\?/\1\~/c
+ :%s/ #\~\(\S\+\)/\*\~\1/c
+ :%s/^#{\~\?\s*/% /c
+ :%s/^r{ /<< /c
+ :%s/\~e/\~^/c
+ :%s/[-~]{ /^\~ /c
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 21 Jun 2005 03:35:13 +0100
+
+sisu (0.15.2-1) unstable; urgency=low
+
+ * bugfix for composite documents, place newline
+ and mark end of import
+ (bug also in current stable 0.14.6)
+
+ * bugfix for [html] endnotes introduced (in param)
+ in development branch
+
+ * number paragraph in given heading sequence
+ while escaping from being a heading 5~- 6~-
+
+ * filenames for termsheet and standard_form
+ sisu -t
+
+ * fix webrick port settings sysenv
+
+ * html subtoc touch required
+
+ * cgi example touched
+
+ * help files updated on syntax changes
+
+ * vim syntax files updated
+
+ * testing required
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 21 Jun 2005 01:54:38 +0100
+
+sisu (0.15.1-1) unstable; urgency=low
+
+ * Syntax Changes, WARNING breaks old syntax,
+
+ * endnotes where not embedded within text,
+ i.e. endnote following paragraph with endnote marker
+ ~^ replaces ~e as marker within text
+ ^~ for endnote content instead of -{ or ~{ [at the start of a
+ line]
+ {~^ shortcut for making link with url as endnote }http://url
+ instead of {~e previous shortcut}http://url
+
+ * help files updated on syntax changes
+
+ * vim syntax files updated
+
+ * extensive testing required
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 20 Jun 2005 04:17:13 +0100
+
+sisu (0.15.0-1) unstable; urgency=low
+
+ * syntax change, WARNING breaks old syntax,
+ a theme is the reduction of characters,
+ and the removal of most uclosed curly braces where used previously
+
+ * to mark headers and heading levels:
+ ^[0-6~{ }~ replaces ^[0-6]\{~?
+ header & headings marked by digit tilde at start of the line
+ tilde replacing unclosed curly brace occuring after
+ digit at beginning of line
+ vim:
+ :%s/\([0-6]\){\~\?/\1\~/c
+ * to provide html name tag within text:
+ *~name replaces #~name
+ vim:
+ :%s/ #\~\(\S\+\)/\*\~\1/c
+ * a comment:
+ ^% replacing ^#{
+ ^%% fold set in vim for such comment marker
+ vim:
+ :%s/^#{ /% /c
+ * require external document fold marker
+ << replacing r{
+ vim:
+ :%s/^r{ /<< /c
+ header and headings change is fairly major as affects most code
+ worth the break, i think so, given goal of simplicity and minimalism
+ however, syntax higlighting becomes even more crucial
+ as becomes more difficult to spot headings otherwise
+ NB summary of vim conversions:
+ :%s/\([0-6]\){\~\?/\1\~/c
+ :%s/ #\~\(\S\+\)/\*\~\1/c
+ :%s/^#{ /% /c
+
+ * help files updated on syntax changes
+
+ * vim syntax files updated
+
+ * extensive testing required
+
+ -- Ralph Amissah <ralph@amissah.com> Sun, 19 Jun 2005 15:23:19 +0100
+
+sisu (0.14.6-1) unstable; urgency=low
+
+ * texpdf removed whitespace around \\href{[url]} in a few locations
+ (latexpdf appears possibly to have problem in passing url to browser
+ including whitespaces before and after url)
+
+ * in all source code headers took out development branch reference,
+ leave it to the download page to keep other urls updated
+ author field Ralph Amissah, (instead of similar email address)
+ propagated alternative name 'Serialized Information, Structured
+ Units'
+ (used earlier but not consistently)
+
+ * skin headers likewise looked at and modified
+
+ * touch to default index.html (in defaults and associated
+ skin)
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 18 Jun 2005 14:10:37 +0100
+
+sisu (0.14.5-1) unstable; urgency=low
+
+ * debian/control sisu now suggests sisu-examples
+
+ * added reference to abandoned U.S. provisional patent application
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 18 Jun 2005 00:14:20 +0100
+
+sisu (0.14.4-1) unstable; urgency=low
+
+ * removed copyright mark from 0{~prefix
+ is distinct from 0{~rights which is related to copyright
+
+ * texpdf - pass author through "special character" filter
+
+ * bug fix for minor numbering using # mark, and re-calibrating
+ removed an extraneous tilde (~)
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 17 Jun 2005 17:12:48 +0100
+
+sisu (0.14.3-1) unstable; urgency=low
+
+ * removed files cgi.rb and cgi_supplies.rb as unused
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 15 Jun 2005 14:36:55 +0100
+
+sisu (0.14.2-1) unstable; urgency=low
+
+ * removed -g option from sisu
+
+ -- ralph <ralph@amissah.com> Tue, 14 Jun 2005 12:15:48 +0100
+
+sisu (0.14.1-1) unstable; urgency=low
+
+ * Documentation, minor changes
+
+ -- ralph <ralph@amissah.com> Tue, 14 Jun 2005 02:06:59 +0100
+
+sisu (0.14.0-1) unstable; urgency=low
+
+ * Flattened directory structure for ./conf/sisu which maps to /etc/sisu
+ or equivalent i.e. removed the additional version number which is
+ not supported by debian packaging, and unnecessary anyway.
+ (this change is the reason for version the hop to 0.14.0)
+
+ * Changed name of ./conf/sisu/sisurc.yaml.sample_disabled,
+ is now ./conf/sisu/sisurc.yaml
+ and enabled with some parts commented out
+
+ * Source Document Digest (using openssl and
+ currently set to MD5) generated
+ were cvs document details requested, (request
+ set in document header).
+
+ * Added man page summary of sisu-examples
+ (and a README for directory which refers
+ you to man page)
+
+ -- ralph <ralph@amissah.com> Sat, 4 Jun 2005 01:08:33 +0100
+
+sisu (0.12.7-1) unstable; urgency=low
+
+ * NOTE: this version deb package was skipped,
+ released as tarball 2005w22/2 (20050601)
+
+ * SiSU made convenient to use to produce other formats (including LaTeX)
+ without the software necessary to produce pdf, i.e. pdflatex
+ http://www.tug.org/applications/pdftex/
+ all this does really is recognise when pdflatex is absent
+ and pdfs cannot be generated in html generated output
+ (i.e. no links to pdf are produced, as was
+ previously the case))
+ where pdf output was assumed)
+
+ * remove tetex-base, tetex-extra require dependency
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 2 Jun 2005 01:21:06 +0100
+
+sisu (0.12.6-1) unstable; urgency=low
+
+ * removed sisu-[version number] executable], is not necessary
+ and did a bit more lintian cleaning
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 26 May 2005 20:22:37 +0100
+
+sisu (0.12.5-1) unstable; urgency=low
+
+ * changed sisu_webrick default port 8081 (from 2000)
+
+ * added short man page for sisu_webrick and sisu_termsheet
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 26 May 2005 18:24:06 +0100
+
+sisu (0.12.4-1) unstable; urgency=low
+
+ * sisu_webrick fix and update
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 26 May 2005 04:54:40 +0100
+
+sisu (0.12.3-1) unstable; urgency=low
+
+ * see changelog
+ man page update
+ added as required the virtual package libyaml-ruby
+
+ -- Ralph Amissah <ralph@amissah.com> Wed, 25 May 2005 18:46:56 +0100
+
+sisu (0.12.2-1) unstable; urgency=low
+
+ * more packaging automation
+ * a fix to rant independent 'installer' file, [& added to auto build]
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 23 May 2005 16:24:29 +0100
+
+sisu (0.12.1-1) unstable; urgency=low
+
+ * start with new source, remove last lintian E message
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 23 May 2005 04:53:40 +0100
+
+sisu (0.12.0-1) unstable; urgency=low
+
+ * auto-debianize sisu using rant and darcs-buildpackage
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 19 May 2005 22:52:27 +0100
+
+sisu (0.10.9-1) unstable; urgency=low
+
+ * [generic rant file]
+
+ * [automating debian package builds]
+
+ -- Ralph Amissah <ralph@amissah.com> Thu, 19 May 2005 22:46:54 +0100
+
+sisu (0.10.8-1) unstable; urgency=low
+
+ * directory remapping
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 16 May 2005 22:27:52 +0100
+
+sisu (0.10.8) unstable; urgency=low
+
+ * Initial Debian release, uploaded by Gunnar Wolf
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 16 May 2005 18:39:35 +0100
diff --git a/debian/compat b/debian/compat
new file mode 100644
index 00000000..45a4fb75
--- /dev/null
+++ b/debian/compat
@@ -0,0 +1 @@
+8
diff --git a/debian/control b/debian/control
new file mode 100644
index 00000000..15462b9e
--- /dev/null
+++ b/debian/control
@@ -0,0 +1,121 @@
+Source: sisu
+Section: text
+Priority: optional
+Maintainer: SiSU Project <sisu@lists.sisudoc.org>
+Uploaders: Ralph Amissah <ralph@amissah.com>
+Build-Depends: debhelper (>= 8)
+Standards-Version: 3.9.3
+Homepage: http://www.sisudoc.org/
+Vcs-Browser: http://git.sisudoc.org/?p=code/sisu.git
+Vcs-Git: git://git.sisudoc.org/git/code/sisu.git
+XS-Dm-Upload-Allowed: yes
+
+Package: sisu
+Architecture: all
+Depends: ${misc:Depends}, ruby1.9.1 (>= 1.9.2.180), rsync, unzip, zip
+Recommends:
+ sisu-pdf, sisu-sqlite, sisu-postgresql, imagemagick | graphicsmagick, keychain,
+ librmagick-ruby, openssl, openssh-client | lsh-client, qrencode, tidy, tree,
+ vim-addon-manager
+Suggests: lv, calibre, pinfo, texinfo, trang
+Conflicts: sisu-markup-samples (<= 1.0.11)
+Replaces: sisu-markup-samples (<= 1.0.11)
+Description: documents - structuring, publishing in multiple formats and search
+ SiSU is a lightweight markup based, command line oriented, document
+ structuring, publishing and search framework for document collections.
+ .
+ With minimal preparation of a plain-text, (UTF-8) file, using its native
+ markup syntax in your text editor of choice, SiSU can generate various
+ document formats (most of which share a common object numbering system for
+ locating content), including plain text, HTML, XHTML, XML, EPUB, OpenDocument
+ text (ODF:ODT), LaTeX, PDF files, and populate an SQL database with objects
+ (roughly paragraph-sized chunks) so searches may be performed and matches
+ returned with that degree of granularity: your search criteria is met by these
+ documents and at these locations within each document. Object numbering is
+ particularly suitable for "published" works (finalized texts as opposed to
+ works that are frequently changed or updated) for which it provides a fixed
+ means of reference of content. Document outputs also share semantic meta-data
+ provided.
+ .
+ SiSU also provides concordance files, document content certificates and
+ manifests of generated output.
+ .
+ A vim syntax highlighting file and an ftplugin with folds for sisu markup is
+ provided, as are syntax highlighting files for kate, kwrite, gedit and
+ diakonos. Vim 7 includes syntax highlighting for SiSU.
+ .
+ man pages, and interactive help are provided.
+ .
+ Dependencies for various features are taken care of in sisu related packages.
+ The package sisu-complete installs the whole of SiSU.
+ .
+ Additional document markup samples are provided in the package
+ sisu-markup-samples which is found in the non-free archive the licenses for
+ the substantive content of the marked up documents provided is that provided
+ by the author or original publisher.
+
+Package: sisu-complete
+Architecture: all
+Depends:
+ ${misc:Depends}, ruby1.9.1 (>= 1.9.2.180), sisu (= ${source:Version}),
+ sisu-pdf (= ${source:Version}), sisu-postgresql (= ${source:Version}),
+ sisu-sqlite (= ${source:Version})
+Description: installs all SiSU related packages
+ SiSU is a lightweight markup based document structuring, publishing and search
+ framework for document collections.
+ .
+ This package installs SiSU and related packages that enable sisu to produce
+ pdf and to populate PostgreSQL and sqlite databases.
+ .
+ See sisu for a description of the package.
+
+Package: sisu-pdf
+Architecture: all
+Depends:
+ ${misc:Depends}, ruby1.9.1 (>= 1.9.2.180), sisu (= ${source:Version}),
+ texlive-latex-base, texlive-fonts-recommended, texlive-latex-recommended,
+ texlive-latex-extra, texlive-xetex, lmodern, ttf-liberation, texlive-math-extra
+Suggests: evince | pdf-viewer
+Description: dependencies to convert SiSU LaTeX output to pdf
+ SiSU is a lightweight markup based document structuring, publishing and search
+ framework for document collections.
+ .
+ This package enables the conversion of SiSU LaTeX output to pdf.
+
+Package: sisu-postgresql
+Architecture: all
+Depends:
+ ${misc:Depends}, ruby1.9.1 (>= 1.9.2.180), sisu (= ${source:Version}),
+ libdbd-pg-ruby1.9.1, libdbi-ruby1.9.1, postgresql, libfcgi-ruby1.9.1
+Suggests: postgresql-contrib
+Description: SiSU dependencies for use with PostgreSQL database
+ SiSU is a lightweight markup based document structuring, publishing and search
+ framework for document collections.
+ .
+ This package enables SiSU to populate a PostgreSQL database. This is done at
+ an object/paragraph level, making granular searches of documents possible.
+ .
+ This relational database feature of SiSU is not required but provides
+ interesting possibilities, including that of granular searches of documents
+ for matching units of text, primarily paragraphs that can be displayed or
+ identified by object citation number, from which an index of documents
+ matched and each matched paragraph within them can be displayed.
+
+Package: sisu-sqlite
+Architecture: all
+Depends:
+ ${misc:Depends}, ruby1.9.1 (>= 1.9.2.180), sisu (= ${source:Version}), sqlite3,
+ libsqlite3-ruby1.9.1, libdbd-sqlite3-ruby1.9.1, libdbi-ruby1.9.1,
+ libfcgi-ruby1.9.1
+Description: SiSU dependencies for use with SQLite database
+ SiSU is a lightweight markup based document structuring, publishing and search
+ framework for document collections.
+ .
+ This package enables SiSU to populate an SQLite database. This is done at an
+ object/paragraph level, making granular searches of documents possible.
+ .
+ This relational database feature of SiSU is not required but provides
+ interesting possibilities, including that of granular searches of documents
+ for matching units of text, primarily paragraphs that can be displayed or
+ identified by object citation number, from which an index of documents
+ matched and each matched paragraph within them can be displayed.
diff --git a/debian/copyright b/debian/copyright
new file mode 100644
index 00000000..c2d61373
--- /dev/null
+++ b/debian/copyright
@@ -0,0 +1,91 @@
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: SiSU
+Upstream-Contact: Ralph Amissah <ralph.amissah@gmail.com>
+Source: http://sisudoc.org/sisu/archive/pool/main/s/sisu/
+ git://git.sisudoc.org/git/code/sisu.git
+
+Files: SiSU *
+Copyright: 1997, 2012, Ralph Amissah
+License: GPL-3+
+
+Files: data/sisu/v*/conf/editor-syntax-etc/emacs/sisu-mode.el
+Copyright: 1997, Ralph Amissah
+ 2011, 2012 Ambrose Kofi Laing, Ralph Amissah (assigned to FSF)
+ 2011, FSF (GNU EMACS) (assigned to)
+License: GPL-3+
+
+Files: data/doc/sisu/markup-samples/samples/free_as_in_freedom.richard_stallman_crusade_for_free_software.sam_williams.sst
+Copyright: 2002, Sam Williams <http://faifzilla.org/>
+License: GFDL-NIV-1.1
+
+Files: data/doc/sisu/markup-samples/samples/free_as_in_freedom_2.richard_stallman_and_the_free_software_revolution.sam_williams.richard_stallman.sst
+Copyright: 2002, Sam Williams
+ 2010, Richard M. Stallman
+ <http://shop.fsf.org/product/free-as-in-freedom-2/>
+License: GFDL-NIV-1.3
+
+Files: setup.rb
+Copyright: 2000-2005 Minero Aoki <http://i.loveruby.net/en/projects/setup/>
+License: LGPL-2.1
+
+Files: debian/*
+Copyright: 2005, Ralph Amissah <ralph.amissah@gmail.com>
+ 2010, SiSU Project Debian, Ralph Amissah
+License: GPL-3+
+
+License: GPL-3+
+ <http://spdx.org/licenses/GPL-3.0+>
+ 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
+ the Free Software Foundation, either version 3 of the License, or
+ (at your option) any later version.
+ .
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+ .
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>.
+ .
+ On Debian systems, the complete text of the GNU General Public License
+ can be found in /usr/share/common-licenses/GPL-3 file.
+
+License: LGPL-2.1
+ <http://spdx.org/licenses/LGPL-2.1>
+ This library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Library General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License.
+ .
+ This library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Library General Public License for more details.
+ .
+ You should have received a copy of the GNU Library General Public
+ License along with this library; if not, write to the Free
+ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ .
+ On Debian systems, the complete text of the GNU Library General Public License
+ can be found in /usr/share/common-licenses/LGPL-2 file.
+
+License: GFDL-NIV-1.1
+ <http://spdx.org/licenses/GFDL-1.1>
+ Permission is granted to copy, distribute and/or modify this
+ document under the terms of the GNU Free Document License, Version 1.1 or any
+ later version published by the Free Software Foundation; with the Invariant
+ Sections being no invariant sections, with the Front-Cover Texts being no
+ invariant sections, and with the Back-Cover Texts being no invariant sections
+ <http://www.gnu.org/copyleft/fdl.html>
+
+License: GFDL-NIV-1.3
+ <http://spdx.org/licenses/GFDL-1.3>
+ Published under the GNU Free Documentation License v1.3 or later.
+ Permission is granted to copy, distribute and/or modify this document under
+ the terms of the GNU Free Documentation License, Version 1.3 or any later
+ version published by the Free Software Foundation; with no Invariant
+ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the
+ license is included in the section entitled "GNU Free Documentation License.
+ <http://www.gnu.org/copyleft/fdl.html>
+
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/_sisu/skin/doc/skin_debian.rb b/debian/data/doc/sisu/markup-samples/samples/v2/_sisu/skin/doc/skin_debian.rb
new file mode 100644
index 00000000..46d29e6c
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/_sisu/skin/doc/skin_debian.rb
@@ -0,0 +1,83 @@
+=begin
+ * Name: SiSU information Structuring Universe - Serialised information, Structured Units
+ * Author: Ralph@Amissah.com
+ * http://www.jus.uio.no/sisu
+ * http://www.jus.uio.no/sisu/SiSU/download
+ * Description: Document skin for SiSU descriptive pages, ...
+ * License: Same as SiSU see http://www.jus.uio.no/sisu
+ * Notes: Site default appearance variables set in defaults.rb
+ Generic site wide modifications set here scribe_skin.rb, and this file required by other "scribes" instead of defaults.rb
+=end
+module SiSU_Viz
+ require "#{SiSU_lib}/defaults" #<url:zxy_defaults.rb>
+ class Skin
+ #% path
+ def path_root
+ './sisu/' # the only parameter that cannot be changed here
+ end
+ def path_rel
+ '../'
+ end
+ #% url
+ def url_root_http
+ 'http://www.jus.uio.no/sisu'
+ end
+ def url_home
+ 'http://www.debian.org/'
+ end
+ def url_site # used in pdf header
+ 'http://www.debian.org'
+ end
+ def url_txt # text to go with url usually stripped url
+ 'www.debian.org'
+ end
+ def url_home_url
+ '../index.html'
+ end
+ #% color
+ def color_band1
+ '"#ffffff"'
+ end
+ def color_band2
+ '"#ffffff"'
+ end
+ #% txt
+ def txt_hp
+ '&nbsp;Debian'
+ end
+ def txt_home
+ 'Debian'
+ end
+ #% icon
+ def icon_home_button
+ 'debian_home.png'
+ end
+ def icon_home_banner
+ home_button
+ end
+ #% banner
+ def banner_home_button
+ %{<table summary="home button" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/">#{png_home}</a></td></tr></table>\n}
+ end
+ def banner_home_and_index_buttons
+ %{<table><tr><td width="20%"><table summary="home and index buttons" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}</td><td width="60%"><center><center><table summary="buttons" border="1" cellpadding="3" cellspacing="0"><tr><td align="center" bgcolor="#ffffff"><font face="arial" size="2"><a href="toc" target="_top">&nbsp;This&nbsp;text&nbsp;sub-&nbsp;<br />&nbsp;Table&nbsp;of&nbsp;Contents&nbsp;</a></font>#{table_close}</center></center></td><td width="20%">&nbsp;#{table_close}}
+ end
+ def banner_band
+ %{<table summary="band" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}}
+ end
+ end
+ class TeX
+ def header_center
+ "\\chead{\\href{#{@vz.url_site}/}{www.debian.org}}"
+ end
+ def home_url
+ "\\href{#{@vz.url_site}/}{www.debian.org}"
+ end
+ def home
+ "\\href{#{@vz.url_site}/}{Debian}"
+ end
+ def owner_chapter
+ "Document owner details"
+ end
+ end
+end
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2.adjusted.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2.adjusted.sst
new file mode 100644
index 00000000..c67e267d
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2.adjusted.sst
@@ -0,0 +1,502 @@
+% SiSU 2.0
+
+@title: Debian Constitution
+ :subtitle: Constitution for the Debian Project (v1.2) [This Document has been Superseded by v1.3]
+
+@creator:
+ :author: Debian Project
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license <br>"Debian" and the Debian Logo http://www.debian.org/logos/ are trademarks of Software in the Public Interest, Inc.
+ :license: This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy, the latest version is usually available at http://www.opencontent.org/openpub/).
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution
+
+@date:
+ :published: 2003-10-29
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2003-10-29
+ :available: 2003-10-29
+ :modified: 2003-10-29
+
+@language:
+ :document: English
+ :original: English
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {Debian Project}http://www.debian.org/
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Site map}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+ {License}http://www.debian.org/license
+
+@notes:
+ :prefix: This Document is Superseded by Version 1.3.<br>This version 1.2 was taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up as a SiSU sample document.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+:A~ Debian Constitution
+
+:B~ Constitution for the Debian Project (v1.2) [This Document has been Superseded by v1.3]
+
+1~pre [Prefix]-#
+
+Version 1.2 ratified on October 29th, 2003. Supersedes {Version 1.1}http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes {Version 1.0}http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.
+
+1~ 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.
+
+1~ 2. Decision-making bodies and individuals
+
+Each decision in the Project is made by one or more of the following:
+
+_1 1. The Developers, by way of General Resolution or an election;
+
+_1 2. The Project Leader;
+
+_1 3. The Technical Committee and/or its Chairman;
+
+_1 4. The individual Developer working on a particular task;
+
+_1 5. Delegates appointed by the Project Leader for specific tasks;
+
+_1 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~ 2.1 General rules
+
+_1 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.
+
+_1 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.
+
+_1 3. A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly.
+
+1~ 3 Individual Developers
+
+2~ 3.1 Powers
+
+An individual Developer may
+
+_1 1. make any technical or nontechnical decision with regard to their own work;
+
+_1 2. propose or sponsor draft General Resolutions;
+
+_1 3. propose themselves as a Project Leader candidate in elections;
+
+_1 4. vote on General Resolutions and in Leadership elections.
+
+2~ 3.2 Composition and appointment
+
+_1 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.
+
+_1 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.}/
+
+2~ 3.3 Procedure
+
+Developers may make these decisions as they see fit.
+
+1~ 4. The Developers by way of General Resolution or election
+
+2~ 4.1 Powers
+
+Together, the Developers may:
+
+_1 1. Appoint or recall the Project Leader.
+
+_1 2. Amend this constitution, provided they agree with a 3:1 majority.
+
+_1 3. Override any decision by the Project Leader or a Delegate.
+
+_1 4. Override any decision by the Technical Committee, provided they agree with a 2:1 majority.
+
+_1 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.
+
+_2 1. A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes.
+
+_2 2. The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines.
+
+_2 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.
+
+_1 6. Together with the Project Leader and SPI, make decisions about property held in trust for purposes related to Debian. (See §9.1.)
+
+2~ 4.2 Procedure
+
+_1 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.
+
+_1 2. Delaying a decision by the Project Leader or their Delegate:
+
+_2 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 s4.1(3).
+
+_2 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).
+
+_2 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.
+
+_2 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.
+
+_2 5. If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+1~ 5. Project Leader
+
+2~ 5.1 Powers
+
+The {Project Leader}http://www.debian.org/devel/leader may:
+
+_1 1. Appoint Delegates or delegate decisions to the Technical Committee.
+
+_1 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.
+
+_1 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.
+
+_1 2. Lend authority to other Developers.
+
+_1 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.
+
+_1 3. Make any decision which requires urgent action.
+
+_1 This does not apply to decisions which have only become gradually urgent through lack of relevant action, unless there is a fixed deadline.
+
+_1 4. Make any decision for whom noone else has responsibility.
+
+_1 5. Propose draft General Resolutions and amendments.
+
+_1 6. Together with the Technical Committee, appoint new members to the Committee. (See §6.2.)
+
+_1 7. Use a casting vote when Developers vote.
+
+_1 The Project Leader also has a normal vote in such ballots.
+
+_1 8. Vary the discussion period for Developers' votes (as above).
+
+_1 9. Lead discussions amongst Developers.
+
+_1 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.
+
+_1 10. Together with SPI, make decisions affecting property held in trust for purposes related to Debian. (See §9.1.)
+
+2~ 5.2 Appointment
+
+_1 1. The Project Leader is elected by the Developers.
+
+_1 2. The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately.
+
+_1 3. For the following three weeks any Developer may nominate themselves as a candidate Project Leader.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+_1 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".
+
+_1 8. The Project Leader serves for one year from their election.
+
+2~ 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.
+
+1~ 6. Technical committee
+
+2~ 6.1 Powers
+
+The {Technical Committee}http://www.debian.org/devel/tech-ctte may:
+
+_1 1. Decide on any matter of technical policy.
+
+_1 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).)
+
+_1 2. Decide any technical matter where Developers' jurisdictions overlap.
+
+_1 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.
+
+_1 3. Make a decision when asked to do so.
+
+_1 Any person or body may delegate a decision of their own to the Technical Committee, or seek advice from it.
+
+_1 4. Overrule a Developer (requires a 3:1 majority).
+
+_1 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.
+
+_1 5. Offer advice.
+
+_1 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.
+
+_1 6. Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.)
+
+_1 7. Appoint the Chairman of the Technical Committee.
+
+_1 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.
+
+_1 8. The Chairman can stand in for the Leader, together with the Secretary
+
+_1 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.
+
+2~ 6.2 Composition
+
+_1 1. The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members.
+
+_1 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.
+
+_1 3. When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6.
+
+_1 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.
+
+_1 5. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee.
+
+2~ 5.3 Procedure
+
+_1 1. The Technical Committee uses the Standard Resolution Procedure.
+
+_1 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.
+
+_1 2. Details regarding voting
+
+_1 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).
+
+_1 3. Public discussion and decision-making.
+
+_1 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.
+
+_1 4. Confidentiality of appointments.
+
+_1 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.
+
+_1 5. No detailed design work.
+
+_1 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.
+
+_1 The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere.
+
+_1 /{Individual members of the technical committee may of course participate on their own behalf in any aspect of design and policy work.}/
+
+_1 6. Technical Committee makes decisions only as last resort.
+
+_1 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.
+
+1~ 7. The Project Secretary
+
+2~ 7.1 Powers
+
+The {Secretary:}http://www.debian.org/devel/secretary
+
+_1 1. Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution.
+
+_1 2. Can stand in for the Leader, together with the Chairman of the Technical Committee.
+
+_1 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.
+
+_1 3. Adjudicates any disputes about interpretation of the constitution.
+
+_1 4. May delegate part or all of their authority to someone else, or withdraw such a delegation at any time.
+
+2~ 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.
+
+2~ 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.
+
+1~ 8. The Project Leader's Delegates
+
+2~ 8.1 Powers
+
+The Project Leader's Delegates:
+
+_1 1. have powers delegated to them by the Project Leader;
+
+_1 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.
+
+2~ 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.
+
+2~ 8.3 Procedure
+
+Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion.
+
+1~ 9. Software in the Public Interest
+
+{SPI}http://www.spi-inc.org/ 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.
+
+2~ 9.1 Authority
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+2~ 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 1. SPI will hold money, trademarks and other tangible and intangible property and manage other affairs for purposes related to Debian.
+
+_1 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.
+
+_1 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.
+
+_1 4. SPI will consider using or disposing of property held in trust for Debian when asked to do so by the Project Leader.
+
+_1 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.
+
+_1 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.
+
+1~a A. Standard Resolution Procedure
+
+These rules apply to communal decision-making by committees and plebiscites, where stated above.
+
+2~a1 A.1. Proposal
+
+The formal procedure begins when a draft resolution is proposed and sponsored, as required.
+
+2~a1a A.1 Discussion and Amendment
+
+_1 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.
+
+_1 2. A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match.
+
+_1 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.
+
+_1 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).)
+
+_1 5. The proposer or 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.
+
+_1 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.
+
+2~a2 A.2. Calling for a vote
+
+_1 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.
+
+_1 2. The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments.
+
+_1 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).
+
+_1 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.
+
+2~a3 A.3. Voting procedure
+
+_1 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).
+
+_1 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.
+
+_1 3. The votes are counted according to the rules in A.6. The default option is "Further Discussion", unless specified otherwise.
+
+_1 4. In cases of doubt the Project Secretary shall decide on matters of procedure.
+
+2~a4 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.
+
+2~a5 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.
+
+2~a6 A.6. Vote Counting
+
+_1 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.
+
+_1 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.
+
+_1 3. Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration.
+
+_2 1. Given two options A and B, V(A,B) is the number of voters who prefer option A over option B.
+
+_2 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).
+
+_2 3. If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1.
+
+_1 4. From the list of undropped options, we generate a list of pairwise defeats.
+
+_1 1. An option A defeats an option B, if V(A,B) is strictly greater than V(B,A).
+
+_1 5. From the list of [undropped] pairwise defeats, we generate a set of transitive defeats.
+
+_1 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.
+
+_1 6. We construct the Schwartz set from the set of transitive defeats.
+
+_2 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.
+
+_1 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.
+
+_2 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 2. A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat.
+
+_1 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.}/
+
+2~b 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.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2.sst
new file mode 100644
index 00000000..c59067d3
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2.sst
@@ -0,0 +1,499 @@
+% SiSU 2.0
+
+@title: Debian Constitution
+ :subtitle: Constitution for the Debian Project (v1.2) [This Document has been Superseded by v1.3]
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution
+
+@date:
+ :published: 2003-10-29
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2003-10-29
+ :available: 2003-10-29
+ :modified: 2003-10-29
+
+@language:
+ :document: English
+ :original: English
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license <br>"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc.
+ :license: This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+:A~ Debian Constitution
+
+:B~ Constitution for the Debian Project (v1.2) [This Document has been Superseded by v1.3]
+
+1~pre [Prefix]-#
+
+Version 1.2 ratified on October 29th, 2003. Supersedes {Version 1.1}http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes {Version 1.0}http://www.debian.org/devel/constitution.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.
+
+1~ Decision-making bodies and individuals
+
+Each decision in the Project is made by one or more of the following:
+
+# The Developers, by way of General Resolution or an election;
+
+# The Project Leader;
+
+# The Technical Committee and/or its Chairman;
+
+# The individual Developer working on a particular task;
+
+# Delegates appointed by the Project Leader for specific tasks;
+
+# 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~ General rules
+
+# 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.
+
+# 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.
+
+# A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly.
+
+1~ Individual Developers
+
+2~ Powers
+
+An individual Developer may
+
+# make any technical or nontechnical decision with regard to their own work;
+
+# propose or sponsor draft General Resolutions;
+
+# propose themselves as a Project Leader candidate in elections;
+
+# vote on General Resolutions and in Leadership elections.
+
+2~ Composition and appointment
+
+# 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.
+
+# 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.}/
+
+2~ Procedure
+
+Developers may make these decisions as they see fit.
+
+1~ The Developers by way of General Resolution or election
+
+2~ Powers
+
+Together, the Developers may:
+
+# Appoint or recall the Project Leader.
+
+# Amend this constitution, provided they agree with a 3:1 majority.
+
+# Override any decision by the Project Leader or a Delegate.
+
+# Override any decision by the Technical Committee, provided they agree with a 2:1 majority.
+
+# 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.
+
+_# A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes.
+
+_# The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines.
+
+_# 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.
+
+# Together with the Project Leader and SPI, make decisions about property held in trust for purposes related to Debian. (See §9.1.)
+
+2~ Procedure
+
+# 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.
+
+# Delaying a decision by the Project Leader or their Delegate:
+
+_# 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 s4.1(3).
+
+_# 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).
+
+_# 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.
+
+_# 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.
+
+_# If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted.
+
+# 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.
+
+# 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.
+
+# 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.
+
+# Votes are cast by email in a manner suitable to the Secretary. The Secretary determines for each poll whether voters can change their votes.
+
+# 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.
+
+1~ Project Leader
+
+2~ Powers
+
+The {Project Leader}http://www.debian.org/devel/leader may:
+
+# 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.
+
+# 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.
+
+# 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.
+
+# Make any decision for whom noone else has responsibility.
+
+# Propose draft General Resolutions and amendments.
+
+# Together with the Technical Committee, appoint new members to the Committee. (See §6.2.)
+
+# Use a casting vote when Developers vote.
+
+The Project Leader also has a normal vote in such ballots.
+
+# Vary the discussion period for Developers' votes (as above).
+
+# 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.
+
+# Together with SPI, make decisions affecting property held in trust for purposes related to Debian. (See §9.1.)
+
+2~ Appointment
+
+# The Project Leader is elected by the Developers.
+
+# The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately.
+
+# For the following three weeks any Developer may nominate themselves as a candidate Project Leader.
+
+# 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.
+
+# 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.
+
+# 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.
+
+# 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".
+
+# The Project Leader serves for one year from their election.
+
+2~ 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.
+
+1~ Technical committee
+
+2~ Powers
+
+The {Technical Committee}http://www.debian.org/devel/tech-ctte may:
+
+# 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).)
+
+# 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.
+
+# 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.
+
+# 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.
+
+# 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.
+
+# Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.)
+
+# 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.
+
+# 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.
+
+2~ Composition
+
+# The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members.
+
+# 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.
+
+# When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6.
+
+# 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.
+
+# If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee.
+
+2~ Procedure
+
+# 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.
+
+# 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).
+
+# 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.
+
+# 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.
+
+# 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.}/
+
+# 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.
+
+1~ The Project Secretary
+
+2~ Powers
+
+The {Secretary:}http://www.debian.org/devel/secretary
+
+# Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution.
+
+# 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.
+
+# Adjudicates any disputes about interpretation of the constitution.
+
+# May delegate part or all of their authority to someone else, or withdraw such a delegation at any time.
+
+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.
+
+2~ 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.
+
+1~ The Project Leader's Delegates
+
+2~ Powers
+
+The Project Leader's Delegates:
+
+# have powers delegated to them by the Project Leader;
+
+# 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.
+
+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.
+
+2~ Procedure
+
+Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion.
+
+1~ Software in the Public Interest
+
+{SPI}http://www.spi-inc.org/ 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.
+
+2~ Authority
+
+# 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.
+
+# 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.
+
+# 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.
+
+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:
+
+# SPI will hold money, trademarks and other tangible and intangible property and manage other affairs for purposes related to Debian.
+
+# Such property will be accounted for separately and held in trust for those purposes, decided on by Debian and SPI according to this section.
+
+# 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.
+
+# SPI will consider using or disposing of property held in trust for Debian when asked to do so by the Project Leader.
+
+# 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.
+
+# 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.
+
+1~a A. Standard Resolution Procedure
+
+These rules apply to communal decision-making by committees and plebiscites, where stated above.
+
+2~a1 A.1. Proposal
+
+The formal procedure begins when a draft resolution is proposed and sponsored, as required.
+
+2~a1a A.1 Discussion and Amendment
+
+# 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.
+
+# A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match.
+
+# 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.
+
+# 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).)
+
+# The proposer or 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.
+
+# 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.
+
+2~a2 A.2. Calling for a vote
+
+# 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.
+
+# The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments.
+
+# 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).
+
+# 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.
+
+2~a3 A.3. Voting procedure
+
+# 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).
+
+# The default option must not have any supermajority requirements. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement.
+
+# The votes are counted according to the rules in A.6. The default option is "Further Discussion", unless specified otherwise.
+
+# In cases of doubt the Project Secretary shall decide on matters of procedure.
+
+2~a4 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.
+
+2~a5 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.
+
+2~a6 A.6. Vote Counting
+
+# 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.
+
+# 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.
+
+# Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration.
+
+_# Given two options A and B, V(A,B) is the number of voters who prefer option A over option B.
+
+_# 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).
+
+_# If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1.
+
+# From the list of undropped options, we generate a list of pairwise defeats.
+
+_# An option A defeats an option B, if V(A,B) is strictly greater than V(B,A).
+
+# From the list of [undropped] pairwise defeats, we generate a set of transitive defeats.
+
+_# 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.
+
+# We construct the Schwartz set from the set of transitive defeats.
+
+_# 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.
+
+# 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.
+
+_# 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).
+
+_# A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat.
+
+# 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.}/
+
+1~b 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.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2~da.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2~da.sst
new file mode 100644
index 00000000..a8a2a274
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2~da.sst
@@ -0,0 +1,501 @@
+% SiSU 2.0
+
+@title: Debians vedtægter
+ :subtitle: Debian-projektets vedtægter (v1.2) [This Document has been Superseded by v1.3]
+
+@creator:
+ :author: Debian Project
+
+@date:
+ :published: 2003-10-29
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2003-10-29
+ :available: 2003-10-29
+ :modified: 2003-10-29
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.da.html <br>"Debian" og Debians logo http://www.debian.org/logos/ er varemærker tilhørende Software in the Public Interest, Inc.<br>Dette er en oversættelse af det originale engelsksprogede dokument http://www.debian.org/license.en.html.
+ :license: Dette materiale må kun distribueres i henhold til vilkårene beskrevet i Open Publication License, udkast (draft) v1.0 eller senere (du kan læse vores lokale kopi http://www.debian.org/opl, den seneste version er normalt tilgængelig på http://www.opencontent.org/openpub/ ).
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution;language:Danish
+
+@language:
+ :document: Danish
+ :original: English
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+:A~ Debians vedtægter
+
+:B~ Debian-projektets vedtægter (v1.2) [This Document has been Superseded by v1.3]
+
+1~pre [Prefix]-#
+
+Version 1.2 blev godkendt den 29. oktober 2003. Erstatter version 1.1 som blev godkendt den 21. juni 2003, der erstattede version 1.0 som blev godkendt den 2. december 1998.
+
+1~1 §1. Introduktion
+
+Debian-projektet er en sammenslutning af personer, som har det fælles mål at udvikle et frit tilgængeligt styresystem.
+
+Dette dokument beskriver organisationsstrukturen for formelle beslutninger i projektet. Det beskriver ikke projektets mål eller hvordan vi opfylder disse, og indeholder ingen retningslinier, bortset fra de retningslinier som direkte vedrører beslutningsprosessen.
+
+1~2 §2. Beslutningsdygtige organer og -personer
+
+Enhver beslutning i projektet er omfattet af en eller flere af følgende:
+
+# Udviklerne, via en fælles resolution eller et valg;
+
+# Projektlederen;
+
+# Den tekniske komité og/eller dennes formand;
+
+# Den individuelle udvikler som arbejder med en bestemt opgave;
+
+# Delegater udnævnt af projektlederen til at varetage særlige opgaver;
+
+# Projektsekretæren.
+
+Resten af dette dokument vil primært beskrive disse organers fuldmagter, deres sammensætning og udnævnelse, og procedurer for vedtagelser. En persons eller et organs fuldmagt kan i visse tilfælde blive genstand for gennemsyn af andre; i så fald vil det fremgå af afsnittet om det organ, der står for dette. I listen ovenfor er hver person eller hvert organ stort set anført før de personer eller organer de kan (hjælpe til med at) udnævne, og hvis beslutninger de kan ophæve - men ikke alle, der er anført tidligere, kan ophæve beslutninger fortaget af alle som er anført senere.
+
+2~2.1 §2.1. Generelle regler
+
+# Intet i disse vedtægter forpligter nogen til at arbejde for projeket. En person, der ikke vil udføre en opgave, som er blevet uddelegeret eller pålagt vedkommende, behøver at gøre det. Derimod kan man ikke aktivt modarbejde regler eller beslutninger, som er foretaget korrekt i henhold til reglerne.
+
+# En person kan bestride flere hverv, bortset fra at projektlederen, projektsekretæren og formanden for den tekniske komité skal være forskellige personer, og lederen kan ikke udnæve sig selv, som sin egen delegat.
+
+# En person kan til enhver tid forlade projektet eller fratræde et særskilt hverv vedkommende har, ved offentligt at erklære dette.
+
+1~3 §3. Individuelle udviklere
+
+2~3.1 §3.1. Fuldmagt
+
+En individuel udvikler kan
+
+# tage tekniske og ikke-tekniske beslutninger med hensyn til sit eget arbejde;
+
+# foreslå og støtte udkast til generelle resolutioner;
+
+# foreslå sig selv som kandidat til projektleder i valg;
+
+# stemme på generelle resolutioner og i ledervalg.
+
+2~3.2 §3.2. Sammensætning og udnævnelse
+
+# Udviklere er frivillige som er enige om at fremme projektets mål for så vidt som de deltager i det, og som vedligeholder pakke(r) for projektet eller gør andet arbejde, som projeketlederens delegater anser for værdifuldt.
+
+# Projektlederens delegater kan vælge ikke at optage nye udviklere, eller at ekskludere nuværende udviklere. Hvis udviklerne mener at delegaterne misbruger deres autoritet, kan de selvfølgelig ophæve en beslutning via en generel resolution - se §4.1(3) og §4.2.
+
+2~3.3 §3.3. Fremgangsmåder
+
+Udviklerne kan foretage disse beslutninger efter eget skøn.
+
+1~4 §4. Udviklerne via generel resolution eller et valg
+
+2~4.1 §4.1. Fuldmagt
+
+Udviklerne kan sammen:
+
+# Udnævne eller afsætte projektlederen.
+
+# Ændre disse vedtægter med et 3:1-flertal.
+
+# Ophæve enhver beslutning taget af projektlederen eller en delegat.
+
+# Ophæve enhver beslutning taget af den tekniske komité, såfremt de er enige med et 2:1-flertal.
+
+# Udgive, erstatte og tilbagetrække ikke-tekniske retningslinier og erklæringer.
+
+Dette inkluderer dokumenter som forklarer projektmål, dets forhold til andre organer indenfor fri software, samt ikke-tekniske vejledninger som de fri software-licensbetingelser, som Debians programmel skal leve op til.
+
+Det kan også være stillingtagen til aktuelle emner.
+
+_# Et grundlæggende dokument er et dokument eller en bekendtgørelse, der betragtes som kritisk for projekts arbejde og formål.
+
+_# De grundlæggende dokumenter er det arbejde som er udmundet i Debian sociale kontrake og Debians retningslinier for fri software.
+
+_# Et grundlæggende dokument kræver et 3:1-flertal for dets erstatning. Nye grundlæggende dokumenter udgives og eksisterende dokumenter trækkes tilbage ved at føje til listen over grundlæggende dokumenter i disse vedtægter.
+
+# Træffe beslutninger sammen med projektlederen og SPI om forvaltede ejendele til formål der har relation til Debian. (Se §9.1).
+
+2~4.1 §4.2. Fremgangsmåde
+
+# Udviklerne følger de generelle resolutionsprocedurer beskrevet nedenfor. En resolution eller ændring betragtes som introduceret, hvis den er foreslået af en hvilken som helst udvikler og mindst K andre udviklere støtter den, eller hvis den er foreslået af projektlederen eller den tekniske komité.
+
+# Udsættelse af en resolution foretaget af projektlederen eller dennes delegater:
+
+_# Hvis projektlederen, dennes delegater eller den tekniske komité har truffet en beslutning, kan udviklerne ophæve denne ved at vedtage en resolution derom, se §4.1(3).
+
+_# Hvis en sådan resolution støttes af mindst 2K udviklere eller hvis den er foreslået af den tekniske komité, vil resolutionen omgående tilsidesætte beslutningen (såfremt resolutionen selv siger dette).
+
+_# Hvis den oprindelige beslutning var at ændre en diskussionsperiode eller en stemmeperiode, eller hvis resolutionens formål er at ophæve en beslutning foretaget af den tekniske komité, behøver kun K udviklere at støtte resolutionen, for omgående at kunne tilsidesætte beslutningen.
+
+_# Hvis beslutningen er tilsidesat, holdes omgående en afstemning for at afgøre om beslutningen skal opretholdes indtil en fuldstændig afstemning om beslutningen kan holdes, eller om udførslen af den oprindelige beslutning skal udsættes indtil da. Der findes ikke et beslutningsdygtigt antal stemmer i denne omgående, proceduriske afstemning.
+
+_# Hvis projektlederen (eller dennes delegater) trækker den oprindelige beslutning tilbage, bliver det uaktuelt at holde afstemningen og den vil ikke blive afholdt.
+
+# Stemmer indsamles af projektsekretæren. Stemmerne og afstemningsresultatet offentliggøres ikke i stemmeperioden; efter afstemningen opremser projektsekretæren alle de afgivne stemmer, Afstemningsperioden er to uger, men projektlederen kan tilføje eller fjerne op til en uge.
+
+# Minimumstiden for diskussion er to uger, men projektlederen kan tilføje eller fjerne op til en uge. Projektlederen har den afgørende stemme. Det beslutningsdygtige antals stemmer er 3Q.
+
+# Forslag, støtte, ændringer, stemmeopråb og andre formelle handlinger foregår via erklæringer på en offentlig tilgængelig elektronisk postliste udvalgt af projektlederens delegat(er); alle udviklere har skriveadgang til den.
+
+# Stemmer afgives via e-mail på en måde der bestemmes af sekretæren. Sekretæren bestemmer for hver afstemning hvorvidt vælgerne kan ændre deres stemmer.
+
+# Q er halvdelen af kvadratroden af antallet af udviklere. K er den mindste af Q og 5. Q og K behøver ikke at være heltal, og de afrundes ikke.
+
+1~5 §5. Projektlederen
+
+2~5.1 §5.1. Fuldmagt
+
+Projektlederen kan:
+
+# Udnævne delegater eller uddelegere beslutninger til den tekniske komité.
+
+Lederen kan beskrive en opgave med løbende ansvar eller en særskilt beslutning. I begge tilfælde overføres denne til en anden udvikler eller til den tekniske komité.
+
+Efter en særskilt beslutning er blevet uddelegeret og afgjort, kan projektlederen ikke trække uddelegeringen tilbage. derimod kan en løbende uddelegerning til en bestemt opgave trækkes tilbage.
+
+# Give hjemmel til andre udviklere.
+
+Projektlederen kan udgive støtteerklæringer til andres synspunkter eller andre projektmedlemmer, uden at være blevet bedt om det. Disse støtteerklæringer er gyldige, hvis, og kun hvis, lederen ville have haft fuldmagt til at træffe den foreliggende beslutning.
+
+# Foretage beslutninger som kræver omgående handling.
+
+Dette gælder ikke beslutninger som gradvist er blevet påtrængende på grund af manglende, relevant handling, med mindre der er en fastsat frist.
+
+# Foretage beslutninger som ingen andre har ansvaret for.
+
+# Fremstille udkast til generelle resolutioner og ændringsforslag.
+
+# Sammen med den tekniske komité udpege nye medlemmer til komitéen. (Se §6.2.)
+
+# Afgive en afgørende stemme i udviklernes afstemninger.
+
+Projektlederen har også almindelig stemmeret i sådanne afstemninger.
+
+# Ændre diskussionsperioden for udviklernes afstemninger (som beskrevet ovenfor).
+
+# Lede diskussioner blandt udviklerne.
+
+Projektlederen bør prøve at deltage i diskussioner blandt udviklerne på en hjælpsom måde, som søger at bringe diskussionen på rette kurs mod sagens kerne. Projektlederen bør ikke bruge lederpositionen til at fremme sine egne personlige synspunkter.
+
+# Tage beslutninger sammen med SPI, der vedrører ejendele som administreres til formål der vedrører Debian. (Se §9.1.)
+
+2~5.2 §5.2. Udnævnelse
+
+# Projektlederen vælges af udviklerne.
+
+# Valget begynder ni uger før lederpositionen bliver ledig eller (hvis det ikke allerede er for sent) omgående.
+
+# I de følgende tre uger kan enhver udvikler nominere sig selv som projektlederkandidat.
+
+# I de efterfølgende tre uger kan der ikke nomineres flere kandidater; kandiaterne bør anvende dette tidsrum til deres valgkamp (for at gøre opmærksom på sig selv og sine synspunkter). Hvis der ikke er nogen kandidater efter nomineringsperioden er slut, bliver perioden udvidet med yderligere tre uger, om nødvendigt gentagne gange.
+
+# De næste tre uger er valgperioden, hvori udviklerene kan stemme. Afstemningen i ledervalg er hemmelig, selv efter afstemningen er afsluttet.
+
+# Valget vil være mellem de kandidater, der har nomineret sig selv og som ikke har trukket sig tilbage, samt Ingen af de nævnte ("None of the Above"). Hvis Ingen af de nævnte vinder valget, bliver denne procedure gentaget, om nødvendigt mange gange.
+
+# Beslutningen træffes ved hjælp af den metode, som er beskrevet i afsnit §A.6 i de generelle resolutionsprocedurer. Det beslutningsdygtige antal er det samme, som ved en generel resolution (§4.2), og standardvalget er Ingen af de nævnte.
+
+# Projektlederen vælges for et år ad gangen.
+
+2~5.3 §5.3. Fremgangsmåde
+
+Projektlederen bør prøve at træffe beslutninger som er i tråd med konsensus blandt udviklerne.
+
+Hvor det er praktisk bør projektlederen på en uformel måde bede om udviklernes synspunkter.
+
+Projektlederen bør undgå at lægge for megen vægt på sine egne synspunkter, når der træffes beslutninger i vedkommendes egenskab af leder.
+
+1~6 §6. Teknisk komité
+
+2~6.1 §6.1. Fuldmagt
+
+Den tekniske komité kan:
+
+# Træffe beslutninger om tekniske retningslinier.
+
+Deriblandt også indholdet af de tekniske retningslinier, udviklernes håndbogsmateriale, pakkeeksempler og hvordan ikke-eksperimentelle pakkeopbygningsværktøjer skal fungere. (I hvert tilfælde træffer den almindelige pakkevedligeholder af programmellet eller dokumentationen, de første beslutninger; se §6.3(5).)
+
+# Afgøre tekniske spørgsmål hvor udviklernes ansvarsområder overlapper.
+
+I tilfælde hvor udviklere skal implementere kompatible tekniske retningslinier eller holdninger (for eksempel hvis de ikke er enige om prioriteringerne ved uforenlige pakker, eller om ejerskab af et kommandonavn, eller om hvilken pakke der er ansvarlig for en fejl som begge pakkevedligeholdere er enige om er en fejl, eller om hvem der bør være vedligeholder af en pakke), kan den tekniske komité afgøre sagen.
+
+# Træffe en beslutning når den bliver bedt om at gøre dette.
+
+Enhver person og ethvert organ kan uddelegere en af sine egne beslutninger til den tekniske komité eller bede om råd fra den.
+
+# Tilsidesætte en udviklers beslutning (kræver et 3:1-flertal)
+
+Den tekniske komité kan bede en udvikler om at benytte en bestemt fremgangsmåde, selvom udvikleren ikke ønsker det; dette kræver et 3:1-flertal. For eksempel kan komitéen komme frem til at en klage fremsat i en fejlrapport er gyldig og at indsenderens foreslåede løsning bør iværksættes.
+
+# Give råd.
+
+Den tekniske komité kan give formelle erklæringer om sit syn på enhvert emne. Individuelle medlemmer kan selvfølgelig give uformelle erklæringer om deres synspunkter og om komitéens sandsynlige synspunkter.
+
+# Sammen med projektlederen udnævne nye medlemmer til sig selv eller fjerne nuværende medlemmer. (Se §6.2.)
+
+# Udnævne formanden for den tekniske komité.
+
+Komitéen vælger formand blandt sine medlemmer. Medlemmerne af komitéen nomineres automatisk; valget starter en uge før stillingen bliver ledig (eller omgående, hvis det allerede er for sent). Medlemmerne kan stemme via offentlig tilkendegivelse for hvilket som helst komitémedlem, også sig selv. Der er intet standardvalg. Valget afsluttes når alle medlemmerne har stemt eller stemmeperioden er afsluttet. Resultatet afgøres ved hjælp af den metode, som er angivet i §A.6 i de generelle resolutionsprocedurer.
+
+# Formanden kan vikariere for lederen, sammen med sekretæren
+
+Som beskrevet i §7.1(2), kan formanden for den tekniske komité og projektsekretæren i fællesskab vikariere for lederen, hvis der ikke er en leder.
+
+2~6.2 §6.2. Sammensætning
+
+# Den tekniske komité består af op til otte udviklere og bør normalt have mindst fire medlemmer.
+
+# Hvis det er mindre end otte medlemmer, kan den tekniske komité anbefale ny(e) medlem(mer) til projektlederen, som (på egen hånd) kan vælge at udnævne dem eller ej.
+
+# Hvis der er fem eller færre medlemmer, kan den tekniske komité udnævne ny(e) medlem(mer) indtil antallet af medlemmer når seks.
+
+# Når der har været fem eller færre medlemmer i mindst en uge, kan projektlederen udnævne nye medlem(mer) indtil antallet af medlemmer når seks, med mindst en uges mellemrum for hver udnævnelse.
+
+# Hvis den tekniske komité og projektlederen er enige kan de fjerne eller erstatte et nuværende medlem af den tekniske komité.
+
+2~6.3 §6.3. Fremgangsmåde
+
+# Den tekniske komité anvender den generelle resolutionsprocedure.
+
+Et udkast til en resolution eller ændring kan framsættes af ethvert medlem af den tekniske komité. Det er ingen minimumstid for diskussion; valgperioden varer i op til en uge eller indtil der ikke længere kan være nogen tvivl om resultatet. Medlemmerne kan ændre deres stemmer. Det beslutningsdygtige antal er to.
+
+# Detaljerede afstemningoplysninger
+
+Formanden har den afgørende stemme. Når den tekniske komité stemmer for at afgøre, om de skal tilsidesætte en afgørelse taget af en udvikler, der også er et medlem af komitéen, kan dette medlem ikke stemme (med mindre det er formanden, som i dette tilfælde kun kan benytte sin afgørende stemmeret).
+
+# Offentlig diskussion og afgørelser
+
+Diskussioner, udkast til resolutioner og ændringer og komitemedlemmernes stemmer offentliggøres på den tekniske komités offentlige diskussionsliste. Der er ikke en særskilt sekretær for komitéen.
+
+# Fortrolighed ved udnævnelser
+
+Den tekniske komité kan holde fortrolige diskussioner via privat e-mail eller en privat postliste, eller på andre måder diskutere udnævnelser til komitéen. Derimod skal stemmerne ved udnævnelser offentliggøres.
+
+# Ikke et detaljeret udviklingsarbejde
+
+Den tekniske komité giver sig ikke i kast med fremstilling af nye forslag og retningslinier. Sådant udviklingsarbejde bør foretages privat af personer eller grupper, og diskuteres i almindelige tekniske og udviklingsfora.
+
+Den tekniske komité begrænser sig selv til at vælge blandt, eller vælge et kompromis mellem, løsninger og afgørelser, der er blevet foreslået og er blevet drøftet tilpas meget andre steder.
+
+Medlemmer af den tekniske komité kan selvfølgelig deltage på egne vegne i alle aspekter af udviklings- og retningsliniearbejde.
+
+# Den teknisk komité træffer kun afgørelser som en sidste udvej
+
+Den tekniske komité træffer ikke en teknisk afgørelse før der uden held har været gjort forsøg på at løse problemet ved konsensus, med mindre den er blevet bedt om at træffe en afgørelse af personen eller organet, der normalt ville have haft ansvar for at gøre dette.
+
+1~7 §7. Projektsekretæren
+
+2~7.1 §7.1. Fuldmagt
+
+Sekretæren:
+
+# Indsamler stemmer fra udviklerne, finder ud af hvor mange udviklere der er og hvem de er, når dette kræves af vedtægterne.
+
+# Kan vikariere for lederen, i fællesskab med formanden for den tekniske komité.
+
+Hvis der ikke er en projektleder, kan formanden for den tekniske komité og projektsekretæren træffe afgørelser ved enighed, hvis de mener at det er vigtigt at gøre dette.
+
+# Dømmer i stridigheder om tolkning af vedtægterne.
+
+# Kan uddelegere dele af eller hele sin fuldmagt til andre, eller til enhver tid trække en sådan uddelegering tilbage.
+
+2~7.2 §7.2. Udnævnelse
+
+Projektsekretæren udnævnes af projektlederen og den forrige projektsekretær.
+
+Hvis projektlederen og den forrige projektsekretær ikke kan blive enige om en ny udnævnelse, skal de bede SPI's bestyrelse (se §9.1) om at udnævne en ny sekretær.
+
+Hvis der ikke er en projektsekretær eller den forrige sekretær ikke kan træffes og ikke har uddelegeret sin fuldmagt til en sådan beslutning, kan beslutningen træffes eller uddelegeres af formanden for den tekniske komité, som fungerende sekretær.
+
+Projektsekretæren er valgt for et år ad gangen, hvorefter en ny (gen)udnævnelse er nødvendig.
+
+2~7.3 §7.3. Fremgangsmåde
+
+Projektsekretæren bør træffe afgørelser som er retfærdige og rimelige, og helst i overensstemmelse med konsensus blandt udviklerne.
+
+Når projektsekretæren og formanden for den tekniske komité i fællesskab vikarierer for en projektleder som ikke kan træffes, bør de kun træffe beslutninger som er helt nødvendige og kun når det er i overensstemmelse med konsensus blandt udviklerne.
+
+1~8 §8. Projektlederens delegater
+
+2~8.1 §8.1. Fuldmagt
+
+Projektlederens delegater:
+
+# har fået uddelegeret en fuldmagt fra projektlederen;
+
+# kan træffe visse afgørelser som lederen ikke kan tage på egen hånd, deriblandt optagelse eller afvisning af udviklere, eller udnævne folk der ikke håndterer pakker, som udviklere. Dette er for at undgå en magtkoncentration hos projektlederen, særligt med hensyn til udviklermedlemskab.
+
+2~8.2 §8.2. Udnævnelse
+
+Delegaterne udnævnes af projektlederen, og lederen kan udskifte dem, som han finder det passende. Projektlederen kan ikke gøre udnævnelse betinget af at delegaten træffer bestemte afgørelser, lederen kan heller ikke ophævne en beslutning truffet af en delegat.
+
+2~8.3 §8.3. Fremgangsmåde
+
+Delegater kan til enhver tid træffe afgørelser, men bør prøve at opnå gode tekniske vilkår og/eller følge konsensus.
+
+1~9 §9. Software in the Public Interest ("Software i offentlighedens interesse")
+
+SPI og Debian er adskilte organisationer, der har nogle fælles mål. Debian er taknemlig for det juridiske støtteapparat, som SPI tilbyder. Debians udviklere er pt. medlemmer af SPI i kraft af deres hverv som udviklere.
+
+2~9.1 §9.1. Fuldmagt
+
+# SPI har ingen fuldmagt hvad angår Debians tekniske eller ikke-tekniske beslutninger, bortset fra at ingen beslutninger foretaget af Debian som vedrører ejendele der administreres af SPI, kan kræve at SPI handler udenfor sin juridiske fuldmagt, og Debians vedtægter kan af og til gøre SPI til en afgørende myndighed, som en sidste udvej.
+
+# Debian har ingen bestemmende kontrol over SPI, bortset fra anvendelse af visse ejendele som beskrevet nedenfor, selvom Debians udviklere kan få fuldmagt indenfor SPI efter SPI's regler.
+
+# Debians udviklere er ikke repræsentanter for, eller ansat af, SPI, eller af personer med fuldmagt i Debian-projektet. En person der handler som udvikler, gør dette som et individ på egne vegne.
+
+2~9.2 §9.2. Administration af ejendele til formål som vedrører Debian
+
+Da Debian ikke har fuldmagt til at forvalte penge eller ejendele, skal donationer til Debian-projektet gives til SPI, som håndterer den slags.
+
+SPI har påtaget sig følgende:
+
+# SPI vil forvalte penge, varemærker, andre konkrete ejendele og forretninger til formål som vedrører Debian.
+
+# Sådanne ejendele vil der blive holdt særskilt regnskab for og blive indsat i en fond med det formål, udvalgt af Debian og SPI i henhold til denne paragraf.
+
+# SPI vil ikke afhænde eller anvende ejendele, de administrerer for Debian, uden samtykke med Debian, som kan gives af projektlederen eller via en generel resolution blandt udviklerne.
+
+# SPI vil overveje anvendelse og/eller afhændelse af ejendele de administrerer for Debian, når de bliver bedt om det af projektlederen.
+
+# SPI vil anvende eller afhænde ejendele som administreres for Debian når de bliver bedt om at gøre dette, via en generel resolution blandt udviklerne, såfremt dette er foreneligt med SPI's juridiske fuldmagt.
+
+# SPI vil via elektronisk post til en af Debian-projektets postlister, gør opmærksom på når ejendele, der administreres for Debian, anvendes eller afhændes.
+
+1~a A. Generel resolutionsprocedure
+
+Disse regler gælder fælles beslutninger truffet af komitéer og ved afstemninger, som beskrevet ovenfor.
+
+2~a1 A.1. Forslag
+
+Den formelle procedure begynder når et udkast til en beslutning er foreslået og støttet, som krævet.
+
+2~a1a A.1. Diskussion og ændring
+
+# Efter forslaget er fremsat, kan resolutionen diskuteres. Ændringsforslag kan gøres formelle ved at fremsætte dem og skaffe støtter jævnfør kravene for nye resolutioner, eller direkte af forslagsstilleren af det oprindelige forslag.
+
+# Et formelt ændringsforslag kan accepteres af resolutionens forslagsstiller, hvorved det formelle resolutionsudkast omgående ændres.
+
+# Hvis et formelt ændringsforslag ikke accepteres, eller en af støtterne til resolutionen ikke er enig med forslagsstillerens accept af et formelt ændringsforslag, holdes en særskilt afstemning om dette.
+
+# Hvis andre ikke kan lide et ændringsforslag, som er accepteret af den oprindelige forslagsstiller, kan de foreslå en anden ændring for at fjerne den tidligere ændring (igen skal de leve op til kravene om forslagsstiller og støtte(r).)
+
+# Forslagsstilleren af en resolution kan foreslå revideringer af formuleringen af ændringensforslaget; disse træder i kraft hvis forslagsstilleren af ændringsforslaget er enig og ingen af støtterne protesterer. I så fald stemmes der om det reviderede ændringsforslag i stedet for det oprindelige.
+
+# Forslagsstilleren af en resolution kan foretage ændringer for at rette mindre fejl (for eksempel stavefejl eller selvmodsigelser) eller ændringer som ikke forandrer meningen, såfremt ingen protesterer indenfor 24 timer. I disse tilfælde starter minimumsdiskussionsperioden ikke igen.
+
+2~a2 A.2. Afstemning
+
+# Forslagsstilleren eller en støtte til en resolution eller et ændringsforslag kan bede om afstemning efter at minimumstiden for diskussion (hvis en sådan findes) er gået.
+
+# Foreslagsstilleren eller en støtte til en resolution kan bede om en afstemning vedrørende resolutionen eller alle beslægtede ændringsforslag.
+
+# Personen, der beder om en afstemning, fremsætter hvad vedkommende mener resolutionens og alle relevante ændringsforslags ordlyd skal være, og dermed hvilken udformning afstemningen skal have. Dog er det projektsekretæren som træffer den endelige beslutning - se §§ 7.1(1), 7.1(3), og A.3(4).
+
+# Den minimale diskussionsperiode regnes fra det tidspunkt, det sidste formelle ændringsforslag blev accepteret eller fra det tidspunkt hele resolutionen blev fremsat, hvis ingen ændringer er blevet foreslået og accepteret.
+
+2~a3 A.3. Afstemningsprocedure
+
+# Der stemmes på hver resolution og dennes beslægtede ændringsforslag i en enkelt afstemning, der indeholder en valgmulighed som er den originale resolution, hvert ændringsforslag, samt et standardvalg (hvor det er muligt).
+
+# Standardvalget må ikke have krav om et absolut flertal. Valgmuligheder som ikke eksplicit har krav om absolut flertal, har et 1:1-krav.
+
+# Stemmerne tælles jf. reglerne i A.6. Standardvalget er "Yderligere diskussion" ("Further Discussion"), med mindre andet er angivet.
+
+# I tvivlstilfælde skal projektsekretæren afgøre procedurespørgsmål.
+
+2~a4 A.4. Tilbagetrukne resolutioner og ikke-accepterede ændringsforslag
+
+Foreslagsstilleren af en resolution eller et ændringsforslag som ikke er accepteret, kan trække disse tilbage. I så fald kan andre foreslagsstillere overtage og holde resolutionen eller ændringsforslaget i live, dermed bliver den første person der gør dette, den nye foreslagsstiller og de andre bliver støtter, hvis de ikke allerede er det.
+
+En støtte til en resolution eller en ændring kan trække sig tilbage (med mindre resolutionen allerede er blevet accepteret).
+
+Hvis foreslagsstillers og/eller støttes tilbagetrækning betyder at resolutionen ikke har en foreslagsstiller eller der ikke er støtter nok, holdes der ikke en afstemning, med mindre dette udredes før resolutionen udløber.
+
+2~a5 A.5. Udløb
+
+Hvis en foreslået resolution ikke er blevet diskuteret, ændret, stemt på eller på anden måde taget hånd om i fire uger, kan sekretæren udsende en besked om, at den betragtes som tilbagetrukket. Hvis ingen af foreslagets støtter har indvendiger, trækkes foreslaget tilbage.
+
+Sekretæren kan også vedlægge forslag til hvordan man fortsætter, hvis det er relevat.
+
+2~a6 A.6. Stemmeoptælling
+
+# Hver vælgers stemme prioriterer valgmulighederne. Man behøver ikke at prioritere alle valgmulighederne. Prioriterede valgmuligheder betragtes som foretrukne fremfor valgmuligheder, der ikke er prioriteret. Vælgere kan give valgmuligheder samme prioritet. Valgmuligheder, der ikke er prioriteret, betragtes som ligestillede med hinanden. Nærmere oplysninger om hvordan stemmesedlerne skal udfyldes, vil være vedlagt valgindkaldelsen.
+
+# Hvis det beslutningsdygtige antal er R, vil enhver valgmulighed som ikke er standardvalget og som ikke modtager mindst R stemmer, der prioriterer den mulighed højere end standardvalget, vil ikke blivetaget i betragtning.
+
+# Alle (ikke-standard-) valgmuligheder, der ikke overgår standardvalgmuligheden med dens krævede flertalsgrad, tages ikke i betragtning.
+
+_# Med de to valgmuligheder A og B, er V(A,B) antallet af vælgere der foretrækker mulighed A fremfor mulighed B.
+
+_# Valgmulighed A overgår standardvalgmulighed D med flertalsgraden N, hvis V(A,D) er større end N * V(D,A).
+
+_# Hvis et absolut flertal på S:1 er krævet af A, er dennes flertalsgrad S; ellers er flertalsgraden 1.
+
+# Ud fra listen over valgmuligheder der tages i betragtning, genereres en liste over parvise nederlag.
+
+_# Valgmulighed A overgår mulighed B, hvis V(A,B) er større end V(B,A).
+
+# Ud fra en liste over parvise nederlag (som tages i betragtning), genereres en liste over transitive nederlag.
+
+_# Valgmulighed A overgår transitivt mulighed C, hvis A overgår C eller hvis der er en en mulighed B, hvor A overgår B OG B transitivt overgår C.
+
+# Ud fra sættet af transitive nederlag konstruere et Schwartz-sæt.
+
+_# Valgmulighed A er i Schwartz-sættet hvis, for alle B-muligheders vedkommende, A transitivt overgår B, eller B ikke overgår A transitivt.
+
+# Hvis der er nederlag mellem valgmuligheder i Schwartz-sættet, ses der bort fra de svageste af sådanne nederlag i listen over parvise nederlag, og man springer tilbage til trin 5.
+
+_# Nederlaget (A,X) er svagere end nederlaget (B,Y), hvis V(A,X) er mindre end V(B,Y). Hvis (A,X) desuden er svagere end (B,Y), hvis V(A,X) er lig med V(B,Y) og V(X,A) er større end V(Y,B).
+
+_# Et svageste nederlag, er et nederlag hvortil der ikke er et svagere nederlag. Der kan være mere end et af sådanne nederlag.
+
+# Hvis der ikke nogen nederlag i Schwartz-sættet, tages vinderen fra valgmulighederne i Schwartz-sættet. Hvis der kun er en af disse valgmuligheder, er den vinderen. Hvis der er flere valgmuligheder, afgørerer vælgeren med den afgørende stemme, hvem af disse valgmuligheder, der er vinderen.
+
+Bemærk: Valgmuligheder, som vælgerne prioriterer over standardvalgmuligheden, er muligheder de betragter som acceptable. Valgmuligheder, der prioriteres under standardvalgmuligheder, er muligheder, der betragtes som uacceptable.
+
+Når den generelle resolutionsprocedure anvendes, skal teksten som henviser til denne, fastsætte hvad der er tilstrækkeligt for at få et udkast til en resolution foreslået og/eller støttet, hvad minimumstiden for diskussion er, og hvad afstemningsperioden er. Den skal også fastsætte det eventuelle kvalificerede flertal og beslutningsdygtige antal, som skal anvendes.
+
+1~b B. Brug af sprog og typografi
+
+Nutid ("er", for eksempel) betyder at udtrykket er en regel i disse vedtægter. "Kan" og "skal" indikerer at personen eller organet kan anvende skøn. "Bør" betyder at det vil anses som en god ting om hvis sætningen følges, men den er ikke bindende. Tekst markeret som et citat, som dette, er baggrundsmateriale og udgør ikke en del af vedtægterne. Den kan kun anvendes til at hjælpe med at tolke teksten i tvivlstilfælde.
+
+Bemærk: Dette er en oversættelse af det originale engelsksprogede dokument. Brug altid originalen i diskussioner om vedtægterne, da denne dansksprogede udgave er oversætterens fortolkning, som desuden kan indeholde fejl og misforståelser.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2~de.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2~de.sst
new file mode 100644
index 00000000..d1609629
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2~de.sst
@@ -0,0 +1,503 @@
+% SiSU 2.0
+
+@title: Debian-Verfassung
+ :subtitle: Verfassung für das Debian-Projekt (v1.2) [This Document has been Superseded by v1.3]
+
+@creator:
+ :author: Debian Project
+
+@date:
+ :published: 2003-10-29
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2003-10-29
+ :available: 2003-10-29
+ :modified: 2003-10-29
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.de.html <br>"Debian" und das Debian-Logo http://www.debian.org/logos/ sind Warenzeichen von Software in the Public Interest, Inc.<br>Dies ist die deutsche Übersetzung von "Debian's license" http://www.debian.org/license.en.html. In Zweifelsfällen ist das englische Original maßgeblich.
+ :license: Dieses Material darf nur unter den Bestimmungen, die in der Open Publication License, Draft v1.0 oder später (Sie können unsere lokale Kopie lesen http://www.debian.org/opl, die neuste Version ist normalerweise unter unter http://www.opencontent.org/openpub/ verfügbar) festgehalten sind, weitergegeben werden.
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution;language:German
+
+@language:
+ :document: German
+ :original: English
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+% @rights: http://www.debian.org/license Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/ <br>This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ). <br>"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc.
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2.default/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+:A~ Debian-Verfassung
+
+:B~ Verfassung für das Debian-Projekt (v1.2) [This Document has been Superseded by v1.3]
+
+1~pre [Prefix]-#
+
+Dies ist die am 29. Oktober 2003 ratifizierte Version 1.2. Sie ersetzt die am 21. Juni 2003 ratifizierte Version 1.1, welche ihrerseits die am 2. Dezember 1998 ratifizierte Version 1.0 ersetzt.
+
+1~ Einleitung
+
+/{Das Debian-Projekt ist ein Verband von Einzelpersonen, die die Schaffung eines freien Betriebssystem zu ihrem gemeinsamen Anliegen gemacht haben.}/
+
+Dieses Dokument beschreibt die Organisationsstruktur für formelle Entscheidungsfindung innerhalb des Projekts. Es beschreibt nicht die Ziele des Projekts oder wie es diese erreicht, und es enthält keine Richtlinien außer denen, die sich direkt auf den Prozess der Entscheidungsfindung beziehen.
+
+1~ Entscheidungsfindende Organe und Einzelpersonen
+
+Jede Entscheidung innerhalb des Projekts wird von einem oder mehreren der folgenden Organe und Einzelpersonen getroffen:
+
+# Den Entwicklern, durch einen Allgemeinen Beschluss oder eine Wahl.
+
+# Dem Projektleiter;
+
+# Dem Technischen Ausschuss und/oder seinem Vorsitzenden;
+
+# Dem an einer einzelnen Aufgabe arbeitenden Entwickler;
+
+# Vom Projektleiter für bestimmte Aufgaben ernannten Delegierten;
+
+# Dem Projekt-Schriftführer.
+
+Das meiste vom Rest dieses Dokuments beschreibt die Befugnisse dieser Organe, ihre Zusammensetzung und Ernennung und das Verfahren bei ihrer Entscheidungsfindung. Die Befugnisse einer Person oder eines Organs können der Überwachung und/oder Einschränkung durch Andere unterworfen sein; in diesem Fall gibt dies der Eintrag des überwachenden Organs oder der Person an. In der obigen Liste ist eine Person oder ein Organ in der Regel vor irgendwelchen Personen oder Organen aufgeführt, deren Entscheidungen sie aufheben können oder die sie ernennen (oder ihnen dabei helfen) – jedoch kann nicht jeder, der vorher aufgeführt wird, jeden, der nachher aufgeführt wird, überstimmen.
+
+2~ Allgemeine Vorschriften
+
+# Nichts in dieser Verfassung erlegt irgendjemandem die Verpflichtung auf, für das Projekt Arbeit zu verrichten. Eine Person, die eine an sie delegierte oder ihr zugewiesene Aufgabe nicht erledigen möchte, muss es nicht tun. Jedoch darf sie nicht diesen Vorschriften oder Entscheidungen, die nach diesen Vorschriften ordnungsgemäß getroffen wurden, aktiv entgegenwirken.
+
+# Eine Person kann verschiedene Ämter innehaben, mit der Ausnahme, dass sich der Projektleiter, der Projekt-Schriftführer und der Vorsitzende des Technischen Ausschusses unterscheiden müssen, und dass der Projektleiter sich nicht zu seinem eigenen Delegierten ernennen kann.
+
+# Eine Person kann das Projekt verlassen oder ein bestimmtes Amt zu jeder Zeit niederlegen, indem sie dies öffentlich erklärt.
+
+1~ Einzelne Entwickler
+
+2~ Befugnisse
+
+Ein einzelner Entwickler darf
+
+# jede technische oder nicht-technische Entscheidung hinsichtlich seiner eigenen Arbeit treffen;
+
+# einen Entwurf zu einem Allgemeinen Beschluss einbringen oder befürworten;
+
+# sich bei Wahlen selbst als Kandidat für das Amt des Projektleiters vorschlagen;
+
+# bei Allgemeinen Beschlüssen und bei Wahlen über die Leitung abstimmen.
+
+2~ Zusammensetzung und Ernennung
+
+# Entwickler sind Freiwillige, die sich darin einig sind, die Ziele des Projekts insofern zu fördern, als sie an ihm teilhaben, und die ein oder mehrere Pakete für das Projekt betreuen oder andere Arbeit verrichten, welche der oder die Delegierten des Projektleiters als lohnenswert erachten.
+
+# Der oder die Delegierten des Projektleiters können es vorziehen, keine neuen Entwickler aufzunehmen, oder vorhandene Entwickler auszuschließen. Wenn die Entwickler verspüren, dass die Delegierten ihre Autorität missbrauchen, können sie selbstverständlich die Entscheidung durch einen Allgemeinen Beschluss außer Kraft setzen - siehe §4.1(3), §4.2.
+
+2~ Verfahren
+
+Entwickler können diese Entscheidungen treffen, wie sie es für richtig halten.
+
+1~ Die Entwickler durch einen Allgemeinen Beschluss oder Wahl
+
+2~ Befugnisse
+
+Zusammen können die Entwickler
+
+# Den Projektleiter ernennen oder abberufen.
+
+# Diese Verfassung abändern, vorausgesetzt, sie stimmen dem mit einer 3:1-Mehrheit zu.
+
+# Jede vom Projektleiter oder einem Delegierten getroffene Entscheidung außer Kraft setzen.
+
+# Jede vom Technischen Ausschuss getroffene Entscheidung außer Kraft setzen, vorausgesetzt, sie stimmen dem mit einer 2:1-Mehrheit zu.
+
+# Nicht-technische schriftliche Richtlinien und Erklärungen herausgeben, ersetzen und zurückziehen.
+
+Diese beinhalten Dokumente, welche die Ziele des Projekts und seine Beziehung zu anderen Gebilden der Freien Software beschreiben, sowie nicht-technische Richtlinien wie die Lizenzbedingungen für Freie Software, die Debian-Software erfüllen muss.
+
+Sie können auch Positionserklärungen zu Tagesfragen hinzufügen.
+
+_# Ein Gründungsdokument ist ein Dokument oder eine Erklärung, die als entscheidend für den Auftrag und die Zwecke des Projekts betrachtet werden.
+
+_# Die Gründungsdokumente sind die Arbeiten mit dem Titel Debian-Gesellschaftsvertrag und Debian Richtlinien für freie Software.
+
+_# Ein Gründungsdokument benötigt eine 3:1-Mehrheit, um ersetzt zu werden. Durch Abändern der Liste der Gründungsdokumente in dieser Verfassung werden neue Gründungsdokumente herausgegeben und vorhandene zurückgezogen.
+
+# Zusammen mit dem Projektleiter und SPI Entscheidungen über mit Debian in Beziehung stehendes, treuhänderisch verwaltetes Eigentum treffen. (Siehe §9.1.)
+
+2~ Verfahren
+
+# Die Entwickler befolgen das Standard-Beschlussverfahren – siehe weiter unten. Einen Beschluss oder Abänderung wird eingebracht, indem sie von irgendeinem Entwickler beantragt und von mindestens K anderen Entwicklern befürwortet wird, oder wenn sie vom Projektleiter oder Technischen Ausschuss beantragt wird.
+
+# Aufschieben einer Entscheidung des Projektleiters oder seines Delegierten:
+
+_# Wenn der Projektleiter, sein Delegierter oder der Technische Ausschuss eine Entscheidung getroffen hat, können Entwickler diese überstimmen, indem sie dazu einen Beschluss verabschieden; siehe §4.1(3).
+
+_# Wenn ein solcher Beschluss von wenigstens 2K Entwicklern befürwortet oder vom Technischen Ausschuss beantragt wird, vertagt der Beschluss die Entscheidung unmittelbar (vorausgesetzt, dieser Beschluss selbst besagt dies).
+
+_# Falls die ursprüngliche Entscheidung darin bestand, eine Diskussions- oder Abstimmungsfrist zu ändern, oder wenn der Beschluss darin besteht, den Technischen Ausschuss zu überstimmen, dann brauchen nur K Entwickler den Beschluss zu befürworten, um die Entscheidung unmittelbar vertagen zu können.
+
+_# Falls die Entscheidung vertagt wird, wird eine sofortige Abstimmung abgehalten, um zu bestimmen, ob die Entscheidung solange bestehen bleibt, bis die vollständige Abstimmung über die Entscheidung durchgeführt wurde, oder ob die Erfüllung der ursprünglichen Entscheidung bis dahin verzögert wird. Es gibt bei dieser unmittelbaren verfahrensbezogenen Abstimmung kein Quorum.
+
+_# Falls der Projektleiter (oder der Delegierte) die ursprüngliche Entscheidung zurückzieht, so wird die Abstimmung gegenstandslos und wird nicht weiter durchgeführt.
+
+# Der Projekt-Schriftführer lässt abstimmen. Stimmen, Stimmensummen und Ergebnisse werden während der Abstimmungsfrist nicht offen gelegt; nach der Abstimmung listet der Projekt-Schriftführer alle abgegebenen Stimmen auf. Die Abstimmungsfrist beträgt zwei Wochen, kann aber durch den Projektleiter um bis zu eine Woche variiert werden.
+
+# Die Mindestfrist für Diskussionen beträgt zwei Wochen, kann aber durch den Projektleiter um bis zu eine Woche variiert werden. Die Stimme des Projektleiters gibt den Ausschlag. Es gibt ein Quorum von 3Q.
+
+# Anträge, Befürwortungen, Abänderungen, Aufrufe zur Abstimmung und andere formelle Handlungen werden auf einer für die Öffentlichkeit lesbaren Mailingliste bekanntgegeben, die von dem bzw. den Delegierten des Projekt-Leiters bestimmt wird; jeder Entwickler kann dort Beiträge abgeben.
+
+# Stimmen werden in einer für den Schriftführer geeigneten Weise durch E-Mail abgegeben. Der Schriftführer legt für jede Abstimmung fest, ob die Abstimmenden ihre Stimme ändern können.
+
+# Q ist die Hälfte der Quadratwurzel aus der Anzahl der gegenwärtigen Entwickler. K ist Q oder 5, je nachdem, welches davon kleiner ist. Q und K brauchen nicht ganze Zahlen sein und werden nicht gerundet.
+
+1~ Projektleiter
+
+2~ Befugnisse
+
+Der Projektleiter darf
+
+# Delegierte ernennen oder Entscheidungen an den Technischen Ausschuss delegieren.
+
+Der Leiter darf einen Bereich mit fortlaufender Verantwortung oder eine bestimmte Entscheidung festlegen und diese an einen anderen Entwickler oder den Technischen Ausschuss übergeben.
+
+Sobald eine bestimmte Entscheidung delegiert und getroffen wurde, darf der Projektleiter diese Delegierung nicht zurückziehen; jedoch darf er eine fortlaufende Delegierung eines bestimmten Verantwortungsbereichs zurückziehen.
+
+# Anderen Entwicklern Vollmacht erteilen.
+
+Der Projektleiter kann Erklärungen zur Unterstützung von Standpunkten oder von anderen Mitgliedern des Projekts abgeben, gebeten oder ungebeten; diese Erklärungen haben dann und nur dann Kraft, wenn der Projektleiter befugt wäre, die fragliche Entscheidung zu treffen.
+
+# Jede Entscheidung treffen, welche dringende Handlung erfordert.
+
+Dies gilt nicht für Entscheidungen, die nur durch einen Mangel an entsprechenden Maßnahmen allmählich dringend geworden sind, außer wenn es einen festen Stichtag gibt.
+
+# Jede Entscheidung treffen, für die niemand sonst Verantwortung trägt.
+
+# Entwürfe für Allgemeine Beschlüsse und Abänderungen einbringen.
+
+# Zusammen mit dem Technischen Ausschuss neue Mitglieder in den Ausschuss berufen. (Siehe §6.2.)
+
+# Sich einer ausschlaggebenden Stimme bedienen, wenn Entwickler abstimmen.
+
+Der Projektleiter hat auch eine normale Stimme bei solchen Abstimmungen.
+
+# Die Diskussionsfrist für Abstimmungen der Entwickler variieren (wie oben).
+
+# Diskussionen unter Entwicklern leiten.
+
+Der Projektleiter sollte versuchen, an Diskussionen unter den Entwicklern auf eine hilfreiche Weise teilzunehmen, die versucht, die Diskussion zu den vorhandenen Kernproblemen zu bringen. Der Projektleiter sollte nicht seine Leitungsposition benutzen, um seine eigenen persönlichen Ansichten zu befördern.
+
+# Zusammen mit SPI Entscheidungen treffen, die mit Debian in Beziehung stehendes, treuhänderisch verwaltetes Eigentum betreffen. (Siehe §9.1.)
+
+2~ Ernennung
+
+# Der Projektleiter wird von den Entwicklern gewählt.
+
+# Die Wahl beginnt neun Wochen, bevor das Amt der Leitung frei wird, oder (wenn es bereits zu spät ist) sofort.
+
+# In den darauf folgenden drei Wochen kann jeder Entwickler sich selbst als Kandidat für das Amt des Projektleiters nominieren.
+
+# Danach können für drei Wochen keine weiteren Kandidaten nominiert werden; Kandidaten sollten diese Zeit für die Wahlkampagne nutzen (um ihre Person und Positionen bekannt zu machen). Falls es am Ende der Nominierungsfrist keine Kandidaten gibt, so wird die Nominierung um weitere drei Wochen verlängert – falls nötig, wiederholt.
+
+# Die nächsten drei Wochen sind der Abstimmungszeitraum, in der Entwickler ihre Stimmen abgeben können. Stimmen bei Wahlen für das Amt des Projektleiters werden geheimgehalten, sogar nachdem die Abstimmung beendet ist.
+
+# Die Wahlmöglichkeiten auf dem Stimmzettel sind diejenigen Kandidaten, die sich selbst nominiert und die Kandidatur noch nicht zurückgezogen haben, und zusätzlich »Niemand von den Obigen«. Falls »Niemand von den Obigen« die Wahl gewinnt, so wird das Wahlverfahren wiederholt – viele Male, falls nötig.
+
+# Die Entscheidung wird nach der in §A.6 des Standard-Beschlussverfahrens bestimmten Methode getroffen. Das Quorum ist dasselbe wie für einen Allgemeinen Beschluss (§4.2), und die Vorgabe-Wahlmöglichkeit ist »Niemand von den Obigen«.
+
+# Der Projektleiter amtiert nach seiner Wahl ein Jahr lang.
+
+2~ Verfahren
+
+Der Projektleiter sollte versuchen, Entscheidungen zu treffen, die mit dem Meinungskonsens der Entwickler vereinbar sind.
+
+Sofern es praktikabel ist, sollte der Projektleiter sich informell um die Ansichten der Entwickler bemühen.
+
+Der Projektleiter sollte es vermeiden, seinen eigenen Standpunkt übermäßig zu betonen, wenn er in seiner Eigenschaft als Projektleiter Entscheidungen trifft.
+
+1~ Technischer Ausschuss
+
+2~ Befugnisse
+
+Der Technische Ausschuss darf
+
+# Über jede Angelegenheit entscheiden, die technische Grundsätze betrifft.
+
+Dies schließt die Inhalte der Handbücher für technische Richtlinien, Nachschlagematerial für Entwickler, Beispielpakete und das Verhalten nicht-experimenteller Paketbau-Werkzeuge ein. (In jedem dieser Fälle trifft jedoch der übliche Betreuer der entsprechenden Software oder Dokumentation anfänglich Entscheidungen; siehe §6.3.(5).)
+
+# Über jede technische Angelegenheit entscheiden, in der sich die Entscheidungsbefugnisse von Entwicklern überlappen.
+
+In Fällen, bei denen Entwickler technische Richtlinien oder Standpunkte erfüllen müssen, die miteinander vereinbar sind (zum Beispiel, wenn sie über die Priorität miteinander im Konflikt stehender Pakete oder über das Eigentum am Namen eines Befehls verschiedener Meinung sind; oder darüber, welches Paket für einen Fehler verantwortlich ist, bei dem beide Betreuer sich einig sind, dass er ein Fehler ist; oder darüber, wer der Betreuer eines Pakets sein sollte), kann der technische Ausschuss die Angelegenheit entscheiden.
+
+# Eine Entscheidung treffen, wenn er darum gebeten wird.
+
+Jede Person und jedes Organ kann eine eigene Entscheidung an den Technischen Ausschuss delegieren, oder von ihm Rat einholen.
+
+# Einen Entwickler überstimmen (benötigt eine 3:1-Mehrheit).
+
+Der Technische Ausschuss kann einen Entwickler darum bitten, einen bestimmten technischen Handlungsweg zu beschreiten, sogar wenn der Entwickler dies nicht wünscht; dazu wird eine 3:1-Mehrheit benötigt. Zum Beispiel kann der Ausschuss festlegen, dass eine Beanstandung, die vom Einsender eines Fehlerberichts erhoben wurde, gerechtfertigt ist, und dass die vom Einsender vorgeschlagene Lösung erfüllt werden sollte.
+
+# Rat anbieten.
+
+Der Technische Ausschuss kann seine Ansichten über jegliche Angelegenheit formell bekannt machen. Einzelne Mitglieder können natürlich informelle Erklärungen über ihre Ansichten und über die voraussichtlichen Ansichten des Ausschusses abgeben.
+
+# Zusammen mit dem Projektleiter neue Mitglieder in den Ausschuss berufen oder vorhandene Mitglieder abberufen. (Siehe §6.2.)
+
+# Den Vorsitzenden des Technischen Ausschusses ernennen.
+
+Der Vorsitzende wird vom Ausschuss aus seinen Mitgliedern gewählt. Alle Mitglieder des Ausschusses werden automatisch nominiert; der Ausschuss beginnt eine Woche vor dem Freiwerden des Amtes zu wählen (oder sofort, wenn es bereits zu spät ist). Die Mitglieder können durch öffentliche Akklamation (d.h. Zuruf) für jedes Mitglied des Ausschusses stimmen, inklusive ihrer selbst; es gibt keine Vorgabe-Wahlmöglichkeit. Die Abstimmung endet, wenn alle Mitglieder abgestimmt haben, oder wenn die Abstimmungsfrist abgelaufen ist. Das Ergebnis wird durch die in §A.6 des Standard-Beschlussverfahrens bestimmte Methode festgelegt.
+
+# Der Vorsitzende kann den Projektleiter zusammen mit dem Schriftführer vertreten.
+
+Wie in §7.1(2) detailliert beschrieben wird, können der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer zusammen den Projektleiter vertreten, falls es keinen Projektleiter gibt.
+
+2~ Zusammensetzung
+
+# Der Technische Ausschuss besteht aus bis zu 8 Entwicklern und sollte für gewöhnlich mindestens 4 Mitglieder haben.
+
+# Wenn es weniger als 8 Mitglieder gibt, kann der Technische Ausschuss dem Projektleiter ein oder mehrere neue Mitglieder empfehlen, der seinerseits (im Einzelfall) entscheiden kann, ob er sie ernennt oder nicht.
+
+# Wenn es 5 oder weniger Mitglieder gibt, kann der Technische Ausschuss ein oder mehrere Mitglieder ernennen, bis die Anzahl der Mitglieder 6 erreicht.
+
+# Wenn es für mindestens eine Woche 5 oder weniger Mitglieder gegeben hat, kann der Projektleiter ein oder mehrere neue Mitglieder ernennen, bis die Anzahl der Mitglieder 6 erreicht – dies in Abständen von mindestens einer Woche pro Ernennung.
+
+# Falls der Technische Ausschuss und der Projektleiter sich einig sind, können sie ein im Technischen Ausschuss vorhandenes Mitglied entfernen oder ersetzen.
+
+2~ Verfahren
+
+# Der Technische Ausschuss bedient sich des Standard-Beschlussverfahrens.
+
+Ein Beschlussentwurf oder eine Abänderung kann von jedem Mitglied des Technischen Ausschusses vorgeschlagen werden. Es gibt keine Mindestfrist für Diskussionen; die Abstimmungsfrist dauert bis zu einer Woche, oder bis über den Ausgang kein Zweifel mehr besteht. Mitglieder können ihre Stimmen ändern. Das Quorum beträgt 2.
+
+# Einzelheiten, die die Abstimmung betreffen.
+
+Der Vorsitzende hat eine ausschlaggebende Stimme. Wenn der Technische Ausschuss darüber abstimmt, ob ein Entwickler, der ebenfalls Mitglied des Ausschusses ist, überstimmt werden soll, so darf dieser Entwickler nicht abstimmen (es sei denn, er ist der Vorsitzende – in diesem Fall kann er nur seine ausschlaggebende Stimme benutzen).
+
+# Öffentliche Diskussion und Entscheidungsfindung.
+
+Diskussion, Beschlussentwürfe und Abänderungen, sowie Stimmen von Mitgliedern des Ausschusses werden auf der öffentlichen Diskussionsliste des Technischen Ausschusses veröffentlicht. Es gibt keinen gesonderten Schriftführer für den Ausschuss.
+
+# Vertraulichkeit der Ernennungen.
+
+Der Technische Ausschuss kann vertrauliche Diskussionen durch private E-Mail, eine private Mailingliste oder andere Mittel abhalten, um Ernennungen in den Ausschuss zu diskutieren. Jedoch müssen Abstimmungen über Ernennungen öffentlich sein.
+
+# Keine Entwurfsarbeit in Einzelheiten.
+
+Der Technische Ausschuss nimmt nicht am Entwurf neuer Vorschläge oder Richtlinien teil. Solche Entwurfsarbeit sollte von Einzelpersonen für sich oder zusammen durchgeführt werden und in gewöhnlichen Foren für technische Richtlinien und Entwürfe diskutiert werden.
+
+Der Technische Ausschuss beschränkt sich darauf, Kompromisse zwischen Lösungen und Entscheidungen, welche anderswo vorgeschlagen und hinreichend gründlich diskutiert worden sind, auszuwählen oder aufzunehmen.
+
+Einzelne Mitglieder des Technischen Ausschusses können selbstverständlich in eigener Sache an jedem Aspekt der Arbeit an Entwürfen und Richtlinien teilhaben.
+
+# Der Technische Ausschuss fasst Beschlüsse nur als letzten Ausweg.
+
+Der Technische Ausschuss trifft keine technische Entscheidung, solange nicht Anstrengungen, diese durch einen Konsens zu entscheiden, unternommen wurden und fehlgeschlagen sind, außer wenn er von der Person oder dem Organ, das normalerweise dafür verantwortlich ist, darum gebeten wurde, eine Entscheidung zu treffen.
+
+1~ Der Projekt-Schriftführer
+
+2~ Befugnisse
+
+Der Schriftführer
+
+# Lässt unter den Entwicklern abstimmen und bestimmt die Anzahl und Person der Entwickler, wann immer dies die Verfassung erfordert.
+
+# Kann zusammen mit dem Vorsitzenden des Technischen Ausschusses an die Stelle des Projektleiters treten.
+
+Wenn es keinen Projektleiter gibt, können der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer in gegenseitigem Einvernehmen Entscheidungen treffen, wenn sie dies als unumgänglich betrachten.
+
+# Über jegliche Streitigkeit urteilen, die die Auslegung der Verfassung betrifft.
+
+# Kann seine Befugnisse teilweise oder vollständig an jemand anderen übertragen oder eine solche Delegierung zu jeder Zeit zurücknehmen.
+
+2~ Ernennung
+
+Der Projekt-Schriftführer wird vom Projektleiter und dem gegenwärtigen Projekt-Schriftführer ernannt.
+
+Wenn der Projektleiter und der gegenwärtige Projekt-Schriftführer sich nicht auf eine neue Ernennung einigen können, müssen sie den Vorstand von SPI (siehe §9.1.) darum bitten, einen Schriftführer zu ernennen.
+
+Wenn es keinen Projekt-Schriftführer gibt, oder der gegenwärtige Projekt-Schriftführer nicht erreichbar ist und seine Vollmacht über eine Entscheidung nicht abgegeben hat, kann der Vorsitzende des Technischen Ausschusses als stellvertretender Schriftführer die Entscheidung treffen oder delegieren.
+
+Die Amtszeit des Projekt-Schriftführers beträgt 1 Jahr, nach dessen Ablauf dieser oder ein anderer Schriftführer (wieder-)ernannt werden muss.
+
+2~ Verfahren
+
+Der Projekt-Schriftführer sollte gerechte und vernünftige Entscheidungen treffen, die vorzugsweise mit dem Konsens der Entwickler vereinbar sind.
+
+Wenn der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer zusammen stellvertretend für einen abwesenden Projektleiter handeln, sollten sie nur wenn absolut notwendig Entscheidungen treffen, und nur, wenn diese vereinbar mit dem Konsens der Entwickler sind.
+
+1~ Die Delegierten des Projektleiters
+
+2~ Befugnisse
+
+Die Delegierten des Projektleiters
+
+# haben vom Projektleiter an sie delegierte Befugnisse;
+
+# dürfen gewisse Entscheidungen treffen, die der Leiter nicht auf direkte Weise treffen darf. Dazu gehört, Entwickler anzuerkennen oder zu verweisen, oder Personen zu Entwicklern zu bestimmen, die keine Pakete betreuen. Dies dient dazu, eine Konzentration von Macht, besonders eine über Mitgliedschaft von Entwicklern, in den Händen des Projektleiters zu verhindern.
+
+2~ Ernennung
+
+Die Delegierten werden durch den Projektleiter ernannt und können vom Projektleiter nach seinem Ermessen ersetzt werden. Der Projektleiter kann weder die Position des Delegierten von bestimmten Entscheidungen des Delegierten abhängig machen, noch kann er sich über eine Entscheidung hinwegsetzen, die einmal von einem Delegierten getroffen wurde.
+
+2~ Verfahren
+
+Delegierte können Entscheidungen treffen, wie sie es für richtig halten, jedoch sollten sie versuchen, gute technische Entscheidungen zu vollziehen und/oder dem Meinungskonsens zu folgen.
+
+1~ Software in the Public Interest (»Software im öffentlichen Interesse«)
+
+SPI und Debian sind getrennte Organisationen, welche einige Ziele miteinander teilen. Debian ist dankbar für die rechtliche Unterstützung, die SPI anbietet. Die Entwickler von Debian sind gegenwärtig Mitglieder von SPI auf Grund ihres Status als Entwickler.
+
+2~ Befugnis
+
+# SPI hat keine Befugnis, die Debians technische oder nicht-technische Entscheidungen betrifft, mit den Ausnahmen, dass keine Entscheidung durch Debian in Hinsicht auf irgendwelches von SPI verwaltetes Eigentum erfordern darf, dass SPI außerhalb seiner rechtlichen Befugnis handelt, und dass Debians Verfassung SPI gelegentlich als entscheidendes Organ letzter Instanz verwenden darf.
+
+# Debian beansprucht keine Befugnis über SPI außer der über die Verwendung gewissen Eigentums von SPI, wie weiter unten beschrieben wird. Dennoch können den Debian-Entwicklern innerhalb von SPI nach den Vorschriften von SPI Befugnisse erteilt werden.
+
+# Debian-Entwickler sind keine Vertreter oder Angestellte von SPI oder voneinander oder von innerhalb des Debian-Projekts mit Befugnis versehenen Personen. Eine Person, die als Entwickler handelt, tut dies als Einzelperson, im eigenen Namen.
+
+2~ Verwaltung von Eigentum für Zwecke, die mit Debian in Beziehung stehen
+
+Da Debian keine Befugnis hat, Geld oder Eigentum zu besitzen, müssen jegliche Spenden für das Debian-Projekt an SPI gemacht werden, das solche Angelegenheiten handhabt.
+
+SPI hat folgende Zusicherungen gemacht:
+
+# SPI besitzt für mit Debian in Beziehung stehende Zwecke Geld, Warenzeichen und anderes materielle und immaterielle Eigentum und handhabt andere Angelegenheiten.
+
+# Solches Eigentum wird für diese Zwecke, über die Debian und SPI entsprechend dieses Abschnitts entscheiden, treuhänderisch mit separater Rechenschaft verwaltet.
+
+# SPI wird kein für Debian treuhänderisch verwaltetes Eigentum veräußern oder verwenden, ohne dass eine Genehmigung durch Debian vorliegt. Diese kann vom Projektleiter oder durch Allgemeine Beschlüsse der Entwickler erteilt werden.
+
+# SPI wird in Betracht ziehen, treuhänderisch verwaltetes Eigentum zu verwenden oder zu veräußern, wenn es durch den Projektleiter darum gebeten wird.
+
+# SPI wird für Debian treuhänderisch verwaltetes Eigentum verwenden oder veräußern, wenn es durch einen Allgemeinen Beschluss der Entwickler darum gebeten wird, vorausgesetzt, dass dies mit der rechtlichen Befugnis von SPI verträglich ist.
+
+# SPI wird die Entwickler durch E-Mail auf einer Mailingliste des Debian-Projekts benachrichtigen, wenn es für Debian treuhänderisch verwaltetes Eigentum verwendet oder veräußert.
+
+1~a A. Standard-Beschlussverfahren
+
+Diese Vorschriften betreffen gemeinschaftliche Entscheidungsfindung durch Ausschüsse sowie direkte Abstimmungen, wie oben angegeben.
+
+2~a1 A.1. Beantragung
+
+Das formelle Verfahren beginnt, wenn ein Beschlussentwurf beantragt und befürwortet wird, je nach Bedarf.
+
+2~a1a A.1. Diskussion und Abänderung
+
+# Nach der Beantragung kann der Beschluss diskutiert werden. Abänderungen können formell gemacht werden, indem sie entsprechend den Anforderungen an einen neuen Beschluss beantragt und befürwortet werden, oder auf direktem Wege durch den Antragsteller des ursprünglichen Beschlusses.
+
+# Eine formelle Abänderung kann durch den Antragsteller des Beschlusses angenommen werden. In diesem Fall wird der formelle Beschlussentwurf unmittelbar mit der Abänderung in Übereinstimmung gebracht.
+
+# Wenn eine formelle Abänderung nicht angenommen wird, oder einer der Befürworter des Beschlusses nicht mit der Annahme durch den Antragsteller einer formellen Abänderung einverstanden ist, bleibt die Abänderung eine Abänderung und es wird über sie abgestimmt.
+
+# Wenn eine vom ursprünglichen Antragsteller angenommene Abänderung nicht nach dem Geschmack Anderer ist, können diese eine weitere Abänderung einbringen, um die frühere Veränderung umzukehren (wieder müssen sie dann Antragsteller und Befürworter gemäß der Anforderungen sein).
+
+# Der Antragsteller eines Beschlusses kann Veränderungen an der Formulierung von Abänderungen vorschlagen; diese werden wirksam, wenn der Antragsteller der Abänderung damit einverstanden ist und keiner der Befürworter dagegen ist. In diesem Fall wird anstelle der ursprünglichen über die veränderten Abänderungen abgestimmt.
+
+# Der Antragsteller eines Beschlusses kann Veränderungen vornehmen, um unbedeutende Fehler (zum Beispiel Schreibfehler oder Ungereimtheiten) zu berichtigen, oder Veränderungen vornehmen, die nicht den Sinn ändern, vorausgesetzt niemand erhebt innerhalb von 24 Stunden Einwände. In diesem Fall beginnt die Mindestfrist für Diskussionen nicht von vorn.
+
+2~a2 A.2. Aufruf zur Abstimmung
+
+# Der Antragsteller oder ein Befürworter eines Antrages oder einer Abänderung kann zur Abstimmung aufrufen, vorausgesetzt, dass die Mindestfrist für Diskussionen (falls vorhanden) abgelaufen ist.
+
+# Der Antragsteller und jeder Befürworter eines Beschlusses können zu einer Abstimmung über diesen Beschluss und alle damit zusammenhängenden Abänderungen aufrufen.
+
+# Die Person, welche zu einer Abstimmung aufruft, gibt bekannt, welches ihrer Ansicht nach die Formulierung des Beschlusses und relevanter Abänderungen sind, und folglich, welche Form der Stimmzettel annehmen sollte. Dennoch liegt die endgültige Entscheidung über die Form des/der Stimmzettel beim Schriftführer – siehe §§7.1(1), 7.1(3) und A.3(4).
+
+# Die Mindestfrist für Diskussionen zählt ab dem Zeitpunkt, zu dem die letzte formelle Abänderung angenommen wurde, oder ab dem Zeitpunkt, zu dem der ganze Beschluss vorgeschlagen wurde, falls keine Abänderungen vorgeschlagen und angenommen wurden.
+
+2~a3 A.3. Wahlverfahren
+
+# Über jeden Beschluss und die damit zusammenhängenden Abänderungen wird auf einem einzigen Wahlzettel abgestimmt, der jeweils eine Wahlmöglichkeit für den ursprünglichen Beschluss, jede Abänderung und die Vorgabe-Wahlmöglichkeit (wo anwendbar) enthält.
+
+# Die Vorgabe-Wahlmöglichkeit darf keine Supermajorität erfordern. Wahlmöglichkeiten, die nicht explizit eine Supermajorität erfordern, erfordern eine 1:1-Mehrheit.
+
+# Die Stimmen werden nach den Vorschriften in §A.6. gezählt. Die Vorgabe-Wahlmöglichkeit heißt »Weitere Diskussion«, wenn nicht eine andere bestimmt wurde.
+
+# In Zweifelsfällen entscheidet der Projekt-Schriftführer über Angelegenheiten des Verfahrens.
+
+2~a4 A.4. Zurückziehen von Beschlüssen oder nicht angenommenen Abänderungen
+
+Der Antragsteller eines Beschlusses oder einer nicht angenommenen Abänderung kann diese zurückziehen. In diesem Fall können neue Antragsteller hervortreten, um sie am Leben zu halten; dann wiederum wird die erste Person, die dies tut, der neue Antragsteller, und alle anderen werden Befürworter, wenn sie dies nicht bereits sind.
+
+Ein Befürworter eines Beschlusses oder einer Abänderung (es sei denn, sie wurde angenommen) kann seine Befürwortung zurückziehen.
+
+Wenn die Zurückziehung durch den Antragsteller und/oder die Befürworter bedeutet, dass der Beschluss keinen Antragsteller oder nicht genug Befürworter hat, wird über sie nicht abgestimmt, es sei denn, dies wird berichtigt, bevor der Beschluss verfällt.
+
+2~a5 A.5. Verfall
+
+Wenn innerhalb von 4 Wochen ein vorgeschlagener Beschluss nicht diskutiert, nicht abgeändert, darüber abgestimmt oder auf andere Weise behandelt wurde, kann der Schriftführer eine Erklärung abgeben, dass man dabei ist, die Angelegenheit zurückzuziehen. Wenn keiner der Befürworter der Anträge innerhalb einer Woche Einwände erhebt, wird die Angelegenheit zurückgezogen.
+
+Der Schriftführer kann seiner Erklärung, falls angebracht, auch Vorschläge beifügen, wie man weiter vorgehen soll.
+
+2~a6 A.6. Stimmenzählung
+
+# Der Stimmzettel jedes Abstimmenden rangiert die Wahlmöglichkeiten (d.h.: ordnet ihnen einen Rang zu), über die abgestimmt wird. Nicht alle Wahlmöglichkeiten müssen rangiert werden. Rangierte Wahlmöglichkeiten werden als bevorzugt gegenüber allen nicht rangierten Wahlmöglichkeiten betrachtet. Die Abstimmenden können Wahlmöglichkeiten gleichrangig rangieren. Nicht rangierte Wahlmöglichkeiten werden als einander gleichrangig betrachtet. Einzelheiten darüber, wie Stimmzettel ausgefüllt werden können, werden mit in den »Aufruf zur Abstimmung« aufgenommen.
+
+# Falls der Wahlzettel ein Quorum R fordert, werden alle Wahlmöglichkeiten (außer der Vorgabe-Wahlmöglichkeit), die nicht mindestens R Stimmen erhalten, die diese Wahlmöglichkeit gegenüber der Vorgabe-Wahlmöglichkeit höher rangieren, fallen gelassen.
+
+# Jede (nicht-Vorgabe-) Wahlmöglichkeit, die die Vorgabe-Wahlmöglichkeit nicht mit ihrem benötigten Mehrheitsverhältnis überstimmt, wird fallengelassen.
+
+_# Sind zwei Wahlmöglichkeiten A und B gegeben, so ist V(A,B) die Anzahl der Abstimmenden, die Wahlmöglichkeit A gegenüber Wahlmöglichkeit B bevorzugen.
+
+_# Eine Wahlmöglichkeit A besiegt die Vorgabe-Wahlmöglichkeit D mit einem Mehrheitsverhältnis N, falls V(A,D) echt größer als N * V(D,A) ist.
+
+_# Wenn eine Supermajorität von S:1 für A benötigt wird, beträgt ihr Mehrheitsverhältnis S; im anderen Fall ist ihr Mehrheitsverhältnis 1.
+
+# Aus der Liste von nicht fallengelassenen Wahlmöglichkeiten erzeugen wir eine Liste von paarweisen Besiegungen.
+
+_# Eine Wahlmöglichkeit A besiegt eine Wahlmöglichkeit B, falls V(A,B) echt größer als V(B,A) ist.
+
+# Aus der Liste der paarweisen Besiegungen erzeugen wir eine Liste von transitiven Besiegungen.
+
+_# Eine Wahlmöglichkeit A besiegt eine Wahlmöglichkeit C transitiv, falls A C besiegt oder es eine andere Wahlmöglichkeit B gibt, so dass A B besiegt UND B transitiv C besiegt.
+
+# Wir konstruieren die Schwartzsche Menge aus der Menge der transitiven Besiegungen.
+
+_# Eine Wahlmöglichkeit A ist in der Schwartzschen Menge, falls für alle Wahlmöglichkeiten B entweder A transitiv B besiegt, oder B nicht transitiv A besiegt.
+
+# Wenn es Besiegungen zwischen Wahlmöglichkeiten gibt, die in der Schwartzschen Menge liegen, so lassen wir die schwächste solcher Besiegungen aus der Liste der paarweisen Besiegungen fallen und kehren zu Schritt 5 zurück.
+
+_# Eine Besiegung (A,X) ist schwächer als eine Besiegung (B,Y) falls V(A,X) kleiner als V(B,Y) ist. Außerdem ist (A,X) schwächer als (B,Y) falls V(A,X) gleich V(B,Y) ist, und V(X,A) größer als V(Y,B) ist.
+
+_# Eine schwächste Besiegung ist eine Besiegung, die keine andere schwächere Besiegung besitzt. Es kann mehr als eine solche Besiegung geben.
+
+# Falls es keine Besiegungen in der Schwartzschen Menge gibt, wird der Sieger aus den Wahlmöglichkeiten in der Schwartzschen Menge ausgewählt. Falls es nur eine solche Wahlmöglichkeit gibt, ist sie der Sieger. Falls es mehrere Wahlmöglichkeiten gibt, bestimmt der Stimmberechtigte mit der ausschlaggebenden Stimme, welche der Wahlmöglichkeiten siegt.
+
+Anmerkung: Wahlmöglichkeiten, welche die Abstimmenden über die Vorgabe-Wahlmöglichkeit rangieren, sind Wahlmöglichkeiten, die sie annehmbar finden. Unter die Vorgabe-Wahlmöglichkeit rangierte Wahlmöglichkeiten sind Wahlmöglichkeiten, die sie nicht annehmbar finden.
+
+Wenn das Standard-Beschlussverfahren benutzt werden soll, muss der darauf bezugnehmende Text bestimmen, was ausreicht, um einen Beschlussentwurf einzubringen und/oder zu befürworten, wie lange die Mindestfrist für Diskussionen dauert, und wie lange die Abstimmungsfrist dauert. Er muss auch jegliche Supermajorität und/oder das Quorum (und Vorgabe-Wahlmöglichkeit) bestimmen, die zu verwenden sind.
+
+1~b B. Sprachgebrauch und Typographie
+
+Der Präsens Indikativ (zum Beispiel »ist«) bedeutet, dass die Aussage eine Vorschrift in dieser Verfassung ist. »Darf« oder »kann« zeigt an, dass es im Ermessen der Person oder des Organs liegt. »Sollte« bedeutet, dass es als gute Sache betrachtet würde, wenn der Satz befolgt würde, aber er ist nicht bindend. Als Zitat markierter Text, so wie dieser, stellt nur Beweggründe dar, und bildet keinen Teil der Verfassung. Er darf nur dazu benutzt werden, um in Zweifelsfällen bei der Interpretation zu helfen.
+
+Anmerkung des Übersetzers: Obwohl diese Übersetzung mit Sorgfalt erstellt wurde, ist nur der englische Originaltext dieser Verfassung verbindlich.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2~es.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2~es.sst
new file mode 100644
index 00000000..e64c4d63
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2~es.sst
@@ -0,0 +1,517 @@
+% SiSU 2.0
+
+@title: Constitución de Debian
+ :subtitle: Constitución del Proyecto Debian
+ :edition: v1.2
+ :note: [This Document has been Superseded by v1.3]
+
+@creator:
+ :author: Debian Project
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, http://www.spi-inc.org/ Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.es.html <br>"Debian" y el logotipo de Debian http://www.debian.org/logos/ son marcas registradas de Software in the Public Interest, Inc.
+ :license: OJO: Esta es una traducción de la licencia original, y no tiene ningún valor jurídico http://www.debian.org/license.en.html. Si desea ver la versión verdadera debe acudir a la licencia original, en este mismo servidor.<br>Este material sólo puede ser distribuido sujeto a los términos y condiciones indicados en la Licencia de publicaciones abiertas, borrador v1.0 o posterior (puede consultar nuestra copia local http://www.debian.org/opl ; la última versión suele estar disponible en http://www.opencontent.org/openpub/ ).
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution;language:Spanish
+
+@date:
+ :published: 2003-10-29
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2003-10-29
+ :available: 2003-10-29
+ :modified: 2006-11-14
+
+% Última modificación: mar, 14 de nov de 2006, 15:44:29 UTC
+
+@language:
+ :document: Spanish
+ :original: English
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2.default/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+:A~ Constitución de Debian
+
+:B~ Constitución del Proyecto Debian (v1.2) [This Document has been Superseded by v1.3]
+
+1~pre [Prefix]-#
+
+Versión 1.2 ratificada el 29 de octubre de 2003. Sustituye a la versión 1.1 ratificada el 21 de junio de 2003, que a su vez sustituía a la versión 1.0 ratificada el 2 de diciembre de 1998.
+
+1~ 1. Introducción
+
+El Proyecto Debian es una asociación de individuos que han hecho causa común para crear un sistema operativo libre.
+
+Este documento describe la estructura organizativa para la toma de decisiones en el Proyecto. No describe las metas del Proyecto o cómo alcanzarlas, ni contiene ninguna norma excepto aquellas relacionadas directamente con el proceso de toma de decisiones.
+
+1~ 2. Individuos y organismos de toma de decisiones
+
+Cada decisión en el Proyecto la toman uno o más de los siguientes:
+
+# Los Desarrolladores, mediante una Resolución General o una elección;
+
+# El Líder del Proyecto;
+
+# El Comité Técnico o su Presidente (chairman);
+
+# El Desarrollador que trabaja en una tarea determinada;
+
+# Delegados nombrados por el Líder del Proyecto para tareas específicas;
+
+# El Secretario del Proyecto.
+
+La mayoría del resto de este documento le ayudará a formar una idea de las atribuciones de estos organismos, su composición y nombramientos, y el proceso de toma de decisiones. Las atribuciones de una persona u organismo pueden estar sujetos a revisión y/o limitación por parte de terceros; en ese caso el organismo o personas encargadas de la revisión indicarán dicha posibilidad. En la lista anterior, normalmente se lista a una persona u organismo antes de aquellos cuyas decisiones puede anular o a los que escoge (o ayuda a escoger); pero no todos los que se nombran al principio mandan sobre todos los posteriores.
+
+2~ Reglas generales
+
+# Nada en esta constitución impone obligaciones a nadie que trabaje para el Proyecto. Una persona que no quiera hacer la tarea que le ha sido delegada o asignada no necesita hacerla. Sin embargo, no se debe actuar activamente en contra de estas reglas y las decisiones tomadas apropiadamente siguiéndolas.
+
+# Una persona puede ocupar varios puestos, pero el Líder del Proyecto, el Secretario del Proyecto y el Presidente del Comité Técnico deben ser personas distintas, además de que el Líder no puede elegirlos como sus Delegados.
+
+# Una persona puede abandonar el Proyecto o dimitir de un cargo en particular, en cualquier momento, diciéndolo públicamente.
+
+1~ Desarrolladores individuales
+
+2~ Atribuciones
+
+Un Desarrollador puede
+
+# tomar una decisión técnica o no técnica con respecto a su propio trabajo;
+
+# proponer o patrocinar borradores de Resoluciones Generales;
+
+# proponerse a sí mismos como candidatos a Líder del Proyecto durante las elecciones;
+
+# votar en una Resolución General y en las elecciones a Líder.
+
+2~ Composición y nombramiento
+
+# Los Desarrolladores son voluntarios que colaboran para hacer avanzar los objetivos del proyecto mientras participan en él, y que mantienen paquetes para el Proyecto, o realizan alguna otra tarea que el (los) Delegado(s) del Líder del Proyecto consideren adecuada.
+
+# El (o los) Delegado(s) del Líder del Proyecto puede(n) elegir no admitir nuevos Desarrolladores, o expulsar a los que ya lo sean. Si los Desarrolladores consideran que los Delegados están abusando de su autoridad pueden por supuesto anular su decisión mediante la vía de una Resolución General (vea §4.1(3), §4.2).
+
+2~ Procedimiento
+
+Los Desarrolladores pueden tomar estas decisiones según crean adecuado.
+
+1~ Los Desarrolladores mediante una Resolución General o elección
+
+2~ Atribuciones
+
+En conjunto, los Desarrolladores pueden:
+
+# Elegir o cesar al Líder del Proyecto.
+
+# Enmendar esta constitución, siempre que esté de acuerdo con una mayoría de las tres cuartas partes.
+
+# Anular cualquier decisión del Líder del Proyecto o uno de sus Delegados.
+
+# Anular cualquier decisión del Comité Técnico, siempre y cuándo estén de acuerdo dos terceras partes.
+
+# Generar documentos no técnicos sobre normas y declaraciones.
+
+Generar, sustituir y retirar documentos sobre normas y declaraciones no técnicos. -#
+
+Esto incluye documentos que describan los objetivos del proyecto, sus relaciones con otras entidades de software libre, y normas no técnicas tales como los términos de licencias de software libre a los que debe ajustarse el software de Debian.
+
+También pueden formular recomendaciones sobre los asuntos incluidos en el orden del día.
+
+_# Un Documento Fundamental (Foundation Document) es un documento o declaración clasificada como crítica para la misión y propósitos del Proyecto.
+
+_# Los Documentos Fundamentales son las obras tituladas Contrato Social de Debian (Debian Social Contract) y Directrices de Software libre de Debian (Debian Free Software Guidelines).
+
+_# La sustitución de un Documento Fundamental precisa de una mayoría de las tres cuartas partes. Se pueden generar nuevos Documentos Fundamentales y retirar los ya existentes mediante una enmienda a la lista de Documentos Fundamentales en esta constitución.
+
+# Junto con el Líder del Proyecto y SPI, tomar decisiones sobre las propiedades mantenidas en fideicomiso para propósitos relacionados con Debian (Ver §9.1.)
+
+2~ Procedimiento
+
+# Los Desarrolladores seguirán el Procedimiento Estándar de Resolución, que se indica más adelante. Se introduce una resolución o enmienda si algún desarrollador la propone y es apoyado por al menos otros 'K' Desarrolladores, o si es propuesta por el Líder del Proyecto o el Comité Técnico.
+
+# Retraso de una decisión del Líder del Proyecto o sus Delegados:
+
+_# Si el Líder del Proyecto o sus Delegados, o el Comité Técnico han tomado una decisión, los Desarrolladores pueden invalidarla aprobando una resolución que lo haga; vea s4.1(3).
+
+_# Si tal resolución es apoyada por al menos '2K' Desarrolladores, o si es propuesta por el Comité Técnico, provoca que la decisión sea congelada de forma inmediata (siempre que la propia resolución lo indique).
+
+_# Si la decisión original versaba sobre cambiar el periodo de un debate o votación, o si la resolución pretende anular uan decisión del Comité Técnico, entonces sólo hace falta el apoyo de 'K' Desarrolladores para poder congelar inmediatamente la decisión.
+
+_# Si la decisión queda postergada, se votará inmediatamente para determinar si se mantiene la decisión hasta que se produzca una votación formal al respecto, o si se deberá retrasar la implementación de la decisión original hasta entonces. No hay quorum para esta votación inmediata.
+
+_# Si el Líder del Proyecto (o su Delegado) se retracta de la decisión original, la votación se hace innecesaria, y no se lleva a cabo.
+
+# El Secretario del Proyecto toma los votos. Los votos y resultados del recuento no son revelados durante el periodo de votación; una vez terminado, el Secretario del Proyecto publicará todos los votos depositados. El periodo de votación es de dos semanas, pero el Líder del Proyecto puede variarlo en hasta una semana.
+
+# El periodo mínimo de discusión es de dos semanas, pero el Líder del Proyecto puede variarlo en hasta una semana. El Líder tiene un voto decisivo. El quorum es de 3Q.
+
+# Las propuestas, patrocinadores, enmiendas, llamadas a votación y otras acciones formales se anuncian en una lista de correo electrónico pública señalada por el (los) Delegado(s) del Líder del Proyecto. Cualquier desarrollador podrá enviar mensajes a ella.
+
+# Los votos son depositados mediante correo electrónico de una manera que el Secretario considere adecuada. El Secretario determinará, para cada votación, si los votantes pueden cambiar su voto.
+
+# Q es la mitad de la raíz cuadrada del número total de Desarrolladores. K es Q o 5, lo que sea más pequeño. Q y K no tienen por qué ser enteros, y no se les aplica redondeo.
+
+1~ El Líder del Proyecto
+
+2~ Poderes
+
+El Líder del Proyecto puede:
+
+# Nombrar Delegados o delegar decisiones en el Comité Técnico.
+
+El Líder puede definir un área de responsabilidad o una decisión específica y delegarla en otro Desarrollador o en el Comité Técnico.
+
+Una vez que una decisión en particular se haya delegado y se haya tomado, el Líder del Proyecto no puede retirar esa delegación; sin embargo, puede retirar una delegación actual de un área de responsabilidad en particular.
+
+# Ceder autoridad a otros Desarrolladores.
+
+El Líder del Proyecto puede respaldar a otros miembros del proyecto o sus opiniones, tanto si se le solicita como por propia voluntad. Sin embargo, sus declaraciones tendrán «fuerza» si y sólo si se le ha dado potestad para tomar la decisión en cuestión.
+
+# Tomar cualquier decisión que precise una acción urgente.
+
+Esto no se aplica a decisiones que se hayan vuelto urgentes de forma gradual debido a la falta de acción relevante, a menos que haya un plazo fijado.
+
+# Tomar cualquier decisión sobre la que ningún otro tenga responsabilidad.
+
+# Proponer borradores de Resoluciones Generales y enmiendas.
+
+# Junto al Comité Técnico, nombrar nuevos miembros del Comité. (Ver §6.2.)
+
+# Usar su voto decisivo cuando los Desarrolladores votan.
+
+El Líder también dispone de un voto normal en tales votaciones.
+
+# Variar el periodo de discusión de las votaciones de los desarrolladores (tal como se dijo anteriormente).
+
+# Dirigir discusiones entre Desarrolladores.
+
+El Líder debería intentar participar en las discusiones entre Desarrolladores de una manera útil, intentando mantener la discusión dentro de los temas clave. El Líder del Proyecto no debería usar su posición para promocionar sus opiniones personales.
+
+# Junto con SPI, tomar decisiones que afecten a propiedad cedida en préstamo para propósitos relacionados con Debian. (Ver §9.1.)
+
+2~ Nombramiento
+
+# El Líder del Proyecto es elegido por los Desarrolladores.
+
+# La elección comienza nueve semanas antes de que el puesto quede vacante, o (si ya es demasiado tarde) inmediatamente.
+
+# Durante las tres semanas siguientes cualquier Desarrollador puede proponerse a sí mismo como candidato a Líder del Proyecto.
+
+# Durante las siguientes tres semanas, no se podrán proponer más candidatos; los que ya lo sean deberían usar este tiempo para hacer campaña (hacer conocer sus identidades y sus opiniones). Si no hay candidatos al final del periodo de nominación, queda extendido por otras tres semanas, repetidamente si fuera necesario.
+
+# Las tres semanas siguientes constituyen el tiempo de votación, durante el cual los Desarrolladores pueden emitir su voto. Los votos destinados a la elección de un líder se mantendrán en secreto, incluso tras acabar el periodo de elecciones.
+
+# Las opciones que aparezcan en la papeleta serán las de aquellos candidatos que se hayan propuesto a sí mismos, y no se hayan retirado, además de "None Of The Above" (Ninguno de los anteriores). Si None Of The Above gana las elecciones, entonces se ha de repetir el proceso, tantas veces como sea necesario.
+
+# La decisión se tomará usando el método especificado en la sección §A.6 del Procedimiento Estándar de Resolución. El quórum es el mismo que para una Resolución General (§4.2) y la opción por defecto es "None Of The Above".
+
+# El Líder del Proyecto ejerce un año de mandato tras su elección.
+
+2~ Procedimiento
+
+El Líder del Proyecto debería intentar tomar decisiones consistentes con el consenso de las opiniones de los Desarrolladores.
+
+Cuando sea práctico, el Líder debería solicitar informalmente la opinión de los Desarrolladores
+
+El Líder debería evitar presentar sus propios puntos de vista con demasiado énfasis cuando tome decisiones en su calidad de Líder.
+
+1~ Comité técnico
+
+2~ Poderes
+
+El Comité Técnico puede:
+
+# Decidir sobre cualquier norma en materia técnica
+
+Esto incluye el contenido de los manuales de normativa técnica (policy), material de referencia para desarrolladores, paquetes de ejemplo y el comportamiento de herramientas para construcción de paquetes que no sean experimentales. En cada caso, el mantenedor original del software o documentación relevante toma las decisiones iniciales, sin embargo (Ver § 6.3(5)).
+
+# Decidir sobre cualquier materia técnica donde se solape la jurisdicción de los Desarrolladores.
+
+En los casos en que varios Desarrolladores necesiten implementar normas técnicas compatibles (por ejemplo, si no están de acuerdo en las prioridades de paquetes en conflicto, o sobre la propiedad del nombre de una orden, o sobre qué paquete es responsable de un fallo cuando ambos mantenedores están de acuerdo en que es un fallo, o sobre quién debería mantener un paquete), el comité técnico puede decidir sobre el asunto.
+
+# Tomar una decisión cuando se le pida.
+
+Cualquier persona u organismo puede delegar una decisión en el Comité Técnico, o pedirle consejo.
+
+# Imponer su decisión sobre la de un Desarrollador (precisa una mayoría de las tres cuartas partes).
+
+El Comité Técnico puede indicar a un Desarrollador que siga un curso de acción técnico en particular, incluso si no es el que desea; esto precisa una mayoría de las tres cuartas partes. Por ejemplo, el Comité puede determinar que está justificada una queja formulada por quien envía un informe de bug, y que debe implementarse la solución que propuso.
+
+# Ofrecer consejo.
+
+El Comité Técnico puede hacer anuncios formales sobre su punto de vista en cualquier asunto. Los miembros individuales pueden, por supuesto, hacer propuestas informales sobre sus puntos de vista y sobre los del comité.
+
+# Junto con el Líder del Proyecto, nombrar nuevos miembros para sí mismo, o eliminar a los existentes. (Ver §6.2.)
+
+# Nombrar al Presidente del Comité Técnico.
+
+Al Presidente lo elige el Comité de entre sus miembros. Todos los miembros del comité quedan nominados automáticamente; la votación comienza una semana antes de que el puesto quede vacante (o inmediatamente, si ya es demasiado tarde). Los miembros pueden votar por aclamación pública a cualquier colega miembro del comité, incluyéndose a sí mismos; no existe la opción predeterminada. La votación termina cuando todos los miembros hayan emitido su voto, o cuando haya terminado el periodo de votación. El resultado se determina usando el método especificado en la sección A.6 del Procedimiento Estándar de Resolución.
+
+# El Presidente puede ejercer las funciones de Líder, junto con el Secretario.
+
+Como se detalla en la §7.1(2), el Presidente del Comité Técnico y el Secretario del Proyecto pueden, en conjunto, ejercer las funciones del Líder si no hay Líder.
+
+2~ Composición
+
+# El Comité Técnico se compone de hasta 8 Desarrolladores, y normalmente debería tener al menos 4 miembros.
+
+# Cuando hayan menos de 8 miembros, el Comité Técnico puede recomendar nuevos miembros al Líder del Proyecto, quien puede escoger (individualmente) si nombrarlos o no.
+
+# Cuando haya 5 miembros o menos, el Comité Técnico puede nombrar nuevos miembros hasta que su número total llegue a 6.
+
+# Cuando el número de miembros sea de 5 o menos durante al menos una semana, el Líder del Proyecto podrá nombrar nuevos miembros hasta que su número llegue a 6, a intervalos de al menos una semana por nombramiento.
+
+# Si el Comité Técnico y el Líder del Proyecto están de acuerdo, pueden destituir o sustituir a un miembro del Comité Técnico.
+
+2~ Procedimiento
+
+# El Comité Técnico usa el Procedimiento Estándar de Resolución.
+
+Cualquier miembro del Comité Técnico puede proponer un borrador de resolución o enmienda. No hay periodo mínimo de discusión; el periodo de votación dura una semana, o hasta que el resultado esté fuera de duda. Los miembros pueden cambiar sus votos. Existe un quorum de dos.
+
+# Detalles al respecto de la votación
+
+El Presidente dispone de un voto decisivo. Cuando el Comité Técnico vota si se debe anular la autoridad de un Desarrollador que además es miembro del Comité, ese miembro no podrá votar (a menos que sea el Presidente, en cuyo caso sólo podrá usar su voto decisivo).
+
+# Discusión pública y toma de decisiones.
+
+Las discusiones, borradores de resoluciones y enmiendas, y votaciones de los miembros del comité, se hacen públicas en la lista pública de discusión del Comité Técnico. El Comité no dispone de secretario propio.
+
+# Confidencialidad de los acuerdos.
+
+El Comité Técnico puede mantener discusiones confidenciales mediante mensajes electrónicos privados, una lista de correo privada, o cualquier otro medio para discutir acuerdos del Comité. Sin embargo, las votaciones sobre dichos acuerdos deben ser públicas.
+
+# Trabajo de diseño poco detallado.
+
+El Comité Técnico no se encarga del diseño de nuevas propuestas y normas. Tal trabajo de diseño debe ser llevado acabo por individuos de forma privada o conjunta y discutida en los foros ordinarios dedicados al diseño y normativa técnicos.
+
+El Comité Técnico se restringe a sí mismo a adoptar o escoger compromisos entre soluciones y decisiones que hayan sido propuestas y razonablemente discutidas en otro lugar.
+
+Los miembros individuales del comité pueden, por supuesto, participar a título personal en cualquier aspecto del trabajo en diseño y normativa.
+
+# El Comité Técnico toma decisiones sólo como último recurso.
+
+El Comité Técnico no toma decisiones técnicas hasta que hayan fracasado otros esfuerzos para resolverlo por la vía del consenso, a menos que así se lo pida la persona u organismo responsables de dicha decisión.
+
+1~ El Secretario del Proyecto
+
+2~ Poderes
+
+El Secretario:
+
+# Recibe los votos de los Desarrolladores, y determina el número e identidad de los Desarrolladores, siempre que la constitución lo requiera.
+
+# Puede ejercer las funciones de Líder, junto con el Presidente del Comité Técnico.
+
+Si no hay Líder del Proyecto, entonces el Presidente del Comité Técnico y el Secretario del Proyecto pueden tomar decisiones mediante acuerdo si consideran imperativo hacerlo.
+
+# Juzga cualquier disputa sobre interpretaciones de la constitución.
+
+# Puede delegar parte de su autoridad en cualquier otro, o derogar tal delegación en cualquier momento.
+
+2~ Nombramiento
+
+El nuevo Secretario del Proyecto es nombrado por el Líder del Proyecto y por el Secretario que abandona el cargo.
+
+Si el Líder del Proyecto y el Secretario saliente no llegan a un acuerdo sobre el nuevo nombramiento, deberán pedir al Consejo de SPI (ver §9.1.) el nombramiento de un Secretario.
+
+Si no hay Secretario del Proyecto o el Secretario actual no está disponible, y no ha delegado la autoridad para una decisión, entonces el Presidente del Comité Técnico puede tomar tal decisión o delegarla, como Secretario en funciones.
+
+El ejercicio del Secretario del Proyecto dura 1 año, en cuyo momento debe escogerse otro Secretario o ratificarle en el cargo.
+
+2~ Procedimiento
+
+El Secretario del Proyecto debería tomar decisiones que sean justas y razonables, preferiblemente consistentes con el consenso de los Desarrolladores.
+
+Cuando actúen juntos en función del Líder del Proyecto ausente, el Presidente del Comité Técnico y el Secretario del Proyecto deberían tomar decisiones sólo cuando fuera absolutamente necesario y sólo siendo consistentes con el consenso de los Desarrolladores.
+
+1~ Los Delegados del Líder del Proyecto
+
+2~ Poderes
+
+Los Delegados del Líder del Proyecto:
+
+# disponen de los poderes que el Líder del Proyecto haya delegado en ellos;
+
+# pueden tomar ciertas decisiones que el Líder no puede tomar directamente, incluyendo la admisión o expulsión de Desarrolladores o nombramiento de personas como Desarrolladores que no mantienen paquetes. Esto evita la concentración de poder, particularmente sobre la pertenencia al proyecto de un Desarrollador, en manos del Líder del Proyecto.
+
+2~ Nombramiento
+
+Los Delegados son nombrados por el Líder del Proyecto y pueden ser reemplazados a discreción del Líder. El Líder no puede condicionar el puesto de Delegado sobre decisiones particulares que éste tome, ni puede anular una decisión del Delegado, una vez tomada.
+
+2~ Procedimiento
+
+Los Delegados toman las decisiones que crean convenientes, pero debertían intentar implementarlas de una forma técnicamente correcta o siguiente una opinión de consenso.
+
+1~ Software in the Public Interest
+
+SPI y Debian son organizaciones separadas que comparten algunos objetivos. Debian agradece la estructura de soporte legal que le ofrece SPI. Los Desarrolladores de Debian son actualemente miembros de SPI por virtud de su estatus de Desarrollador.
+
+2~ Autoridad
+
+# SPI carece de poder de decisión sobre cuestiones técnicas y de cualquier otro ámbito relacionadas con Debian, con la salvedad de que Debian no podrá imponerse a SPI en ningún caso que contravenga a su autoridad legal sobre las propiedades en poder de SPI, si bien la constitución de Debian podrá recurrir a SPI como órgano decisorio en última instancia
+
+# Debian no pretende autoridad alguna sobre SPI otra que el uso de ciertos bienes de SPI, tal como se describe más adelante, aunque se pueda conceder autoridad dentro de SPI a los Desarrolladores de Debian mediante las propias reglas de SPI.
+
+# Los Desarrolladores de Debian no son agentes comerciales ni empleados de SPI, ni unos de otros, ni de personas con autoridad en el Proyecto Debian. Una persona actuando como Desarrollador lo hace como individuo, en su propio nombre.
+
+2~ Gestión de bienes para propósitos relacionados con Debian
+
+Dado que Debian no puede poseer dinero ni bienes, cualquier donación al Proyecto Debian debe ser dirigida a SPI, que gestiona tales cuestiones.
+
+SPI garantiza lo siguiente:
+
+# SPI actuará como depositario del dinero, marcas registradas y otros bienes tangibles e intangibles y gestionará otros asuntos con propósitos relacionados con Debian.
+
+# Tales bienes serán contabilizados por separado y mantenidos en fideicomiso para dichos propósitos, decididos por Debian y SPI de acuerdo a esta sección.
+
+# SPI no dispondrá de o usará bienes mantenidos en fideicomiso para Debian sin la aprobación de Debian, que debe ser emitida por el Líder del Proyecto o mediante una Resolución General de los Desarrolladores.
+
+# SPI tomará en consideración usar o disponer de bienes mantenidos en fideicomiso para Debian cuando se lo pida el Líder del Proyecto.
+
+# SPI usará o dispondrá de bienes mantenidos en fideicomiso para Debian cuando le sea pedido mediante una Resolución General de los Desarrolladores, siempre que sea compatible con la autoridad legal de SPI.
+
+# SPI informará a los Desarrolladores mediante mensaje electrónico a una lista del Proyecto Debian cuando use o disponga de bienes mantenidos en fideicomiso para Debian.
+
+1~a A. Procedimiento Estándar de Resolución
+
+Estas reglas se aplican a la toma de decisiones comunitaria de comités y plebiscitos, tal como se indicó anteriormente.
+
+2~a1 A.1. Propuesta
+
+El procedimiento formal comienza cuando se propone y patrocina un borrador de resolución, tal como se requiere.
+
+2~a1a A.1. Discusión y Enmienda
+
+# Siguiendo la propuesta, se debe discutir la resolución. Se pueden hacer enmiendas formales proponiéndolas y patrocinándolas de acuerdo a los requerimientos de una nueva resolución, o haciéndolo directamente el proponente de la resolución original.
+
+# El proponente de la resolución puede aceptar una enmienda formal, en cuyo caso se cambia inmediatamente el borrador de la resolución formal para que se ajuste a la enmienda.
+
+# Si no se acepta una enmienda formal, o uno de los patrocinadores de la resolución no está de acuerdo con que el proponente acepte la enmienda formal, se mantiene como enmienda y pasa a ser votada.
+
+# Si una enmienda aceptada por el proponente original no es del gusto de otros, pueden proponer otra enmienda para invertir el cambio anterior (de nuevo, necesitan cumplir los requerimientos de proponente y patrocinador(es).)
+
+# El proponente o una resolución pueden sugerir cambios en el texto de la enmienda; lo cual tendrá efecto si el proponente de la enmienda está de acuerdo y ninguno de sus patrocinadores se opone. En tal caso se votará la enmienda modificada en lugar de la original.
+
+# El proponente de una resolución puede hacer cambios para corregir errores menores (por ejemplo, errores tipográficos o inconsistencias) o cambios que no alteren el significador, siempre que nadie objete en las siguientes 24 horas. En este caso, no se reinicia el periodo mínimo de discusión.
+
+2~a2 A.2. Llamada a urnas
+
+# El proponente o patrocinador de una moción o enmienda puede pedir una votación, siempre que haya pasado el tiempo mínimo de discusión (si es que lo había).
+
+# El proponente o patrocinador de una moción puede pedir una votación sobre esa resolución y todas las enmiendas relacionadas.
+
+# La persona que pide una votación indica el que cree que debería ser el texto de la resolución y cualquier enmienda relevante y, consecuentemente, el contenido de las papeletas. Sin embargo, la decisión final del contenido de las papeletas es del Secretario (Ver 7.1(1), 7.1(3) y A.3(4))
+
+# El periodo mínimo de discusión se cuenta desde el momento en que fue aceptada la última enmienda formal, o el momento en que se propuso la resolución si no se han propuesto y aceptado enmiendas.
+
+2~a3 A.3. Procedimiento de votación
+
+# Cada resolución y sus enmiendas relacionadas se votan en una única papeleta que incluye una opción para la resolución original, cada enmienda, y la opción predeterminada (si se aplica).
+
+# La opción predeterminada no tiene ningún requerimiento de supermayoría. Las opciones que no precisen explícitamente de supermayoría, tienen un requerimiento de mayoría 1:1.
+
+# Los votos se cuentan de acuerdo con las reglas en A.6. La opción predeterminada es "Further Discussion", a menos que se especifique otra cosa.
+
+# En caso de duda, el Secretario del Proyecto decidirá en materia de procedimiento.
+
+2~a4 A.4. Retirada de resoluciones o enmiendas rechazadas
+
+El proponente de una resolución o enmienda rechazada puede retirarla. En este caso, pueden aparecer nuevos proponentes para mantenerlas activas, en cuyo caso la primera persona que lo haga se convierte en el nuevo proponente y cualquier otro se convierte en patrocinador si no los había ya.
+
+El patrocinador de una resolución o enmienda puede retirarse (a menos que sea aceptada).
+
+Si la retirada del proponente o patrocinadores implica que la resolución no tiene proponente o suficientes patrocinadores, no será llevada a votación a menos que se rectifique antes de que la resolución expire.
+
+2~a5 A.5. Expiración
+
+Si una resolución propuesta no ha sido discutida, enmendada, votada o movida de alguna manera durante 4 semanas el secretario puede anunciar que está siendo retirada. Si ninguno de los patrocinadores de cualquiera de las propuestas objeta durante una semana, la resolución se retira.
+
+El secretario también puede incluir sugerencias sobre cómo proceder, si fuera apropiado.
+
+2~a6 A.6. Recuento de votos
+
+# La papeleta de cada votante califica las opciones sobre las que se vota. No hace falta calificar todas las opciones. Las opciones calificadas se consideran preferidas sobre todas las que no lo hayan sido. Los votantes pueden dar la misma calificación a las opciones. Se considera que las no calificadas tienen la misma calificación entre ellas. Se incluirán en la Llamada al voto los detalles de la manera en que se debe rellenar la papeleta.
+
+# Si la papeleta precisa un quórum R, cualquier opción diferente a la predeterminada que no obtenga al menos R votos calificándola por encima de la opción predeterminada se elimina de toda consideración.
+
+# Cualquier opción (que no sea la predeterminada) que no venza a la predeterminada por la proporción de mayoría precisada se elimina de toda consideración.
+
+_# Dadas dos opciones A y B, V(A,B) es el número de votantes que prefieren la opción A sobre la opción B.
+
+_# Una opción A vence a la opción predeterminada D por una proporción de mayoría N, si V(A, D) es estrictamente mayor que N * V(D,A).
+
+_# Si A necesita una supermayoría de S:1, su proporción de mayoría es S; si no, su proporción de mayoría es 1.
+
+# De la lista de opciones sin eliminar, generamos una lista de derrotas a pares.
+
+_# Una opción A vence a una opción B, si V(A,B) es estrictamente mayor que V(B,A).
+
+# De una lista de derrotas a pares (sin eliminar), generamos un conjunto de derrotas transitivas.
+
+_# Una opción A derrota transitivamente a una opción C si A derrota a C o si hay otra opción B donde A derrota a B Y B derrota transitivamente a C.
+
+# Construimos el conjunto de Schwartz partiendo del conjunto de derrotas transitivas.
+
+_# Una opción A está en el conjunto de Schwartz si para todas las opciones B, bien A derrota transitivamente a B, o B no derrota transitivamente a A.
+
+# Si hay derrotas entre opciones en el conjunto de Schwartz, eliminamos a la más débil de tales derrotas de la lista de derrotas por pares, y volvemos al quinto paso.
+
+_# Una derrota (A,X) es más débil que una derrota (B,Y) si V(A,X) es menor que V(B,Y). Además, (A,X) es más débil que (B,Y) si V(A,X) es igual a V(B,Y) y V(X,A) es mayor que V(Y,B).
+
+_# La derrota más débil es aquella que no tiene ninguna derrota más débil que ella. Puede haber más de una de tales derrotas.
+
+# Si no hay derrotas dentro del conjunto de Schwartz, entonces el ganador se escoge de entre las opciones en dicho conjunto. Si sólo hay una de tales opciones, es la ganadora. Si hay varias, el elector con el voto de calidad escoge cual de estas opciones gana.
+
+Nota: Las opciones que los votantes califiquen por encima de la opción predeterminada son aquellas que encuentran aceptables. Las opciones calificadas por debajo de la predeterminada son las que encuentran inaceptables.
+
+Cuando se deba usar el Procedimiento Estándar de Resolución, el texto que se refiera a ello debe especificar si es suficiente tener un borrador o patrocinadores de la resolución propuesta, cual es el periodo mínimo de discusión, y el periodo de votación. También se debe especificar la necesidad de una mayoría absoluta o el quorum (y la opción por defecto) necesario.
+
+1~b B. Uso del lenguaje y tipografía
+
+N. del T.: se refiere al original en ingles.
+
+EL presente indicativo (`is', por ejemplo) indica que la frase es una regla de esta constitución. `May' o `can' indica que la persona u organismo puede actuar a discreción. `Should' indica que se consideraría bien la obediencia a dicha frase, pero no es vinculante. El texto marcado como cita, tal como éste, indica la base lógica del texto, y no forma parte de la constitución. Se debe usar sólo como ayuda en caso de duda.
+
+% Volver a la página principal de Debian.
+% Cómo modificar el idioma por defecto de los documentos
+% Para informar de un problema con el servidor web, por favor, envíe un correo (en inglés) a debian-www@lists.debian.org. Para consultar información de contacto adicional consulte la página de contactos de Debian.
+% Última modificación: mar, 14 de nov de 2006, 15:44:29 UTC
+% Proyecto Debian
+% Elija un servidor cerca de usted
+% Nota: La página original es más nueva que esta traducción.
+% Constitución de Debian
+% Constitución del Proyecto Debian (v1.2)
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2~fr.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2~fr.sst
new file mode 100644
index 00000000..1894c175
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.2~fr.sst
@@ -0,0 +1,508 @@
+% SiSU 2.0
+
+% Dernière modification : jeudi 2 novembre 2006 06:33:05 UTC
+% Copyright © 1997-2006 SPI; voir les termes de la licence.
+% Debian est une marque déposée de Software in the Public Interest, Inc.
+% Note : le document original est plus récent que cette traduction.
+% Constitution Debian
+% Constitution du Projet Debian (v1.2)
+
+@title: Constitution Debian
+ :subtitle: Constitution du Projet Debian (v1.2) [This Document has been Superseded by v1.3]
+ :edition: v1.2
+ :note: [This Document has been Superseded by v1.3]
+
+@creator:
+ :author: Debian Project
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.da.html <br>« Debian » et le logo Debian sont des marques déposées appartenant à Software in the Public Interest, Inc.<br>En cas de litige, seule la version originale de cette page a valeur au regard de la loi http://www.debian.org/license.en.html.
+ :license: Ce matériel ne peut être distribué que conformément aux termes et conditions présentés dans la Licence de Publication Ouverte (Open Publication License), Draft v.1.0 ou suivantes. (Vous pouvez lire notre copie locale http://www.debian.org/opl, dont la version la plus récente est généralement disponible à http://www.opencontent.org/ ).
+
+@date:
+ :published: 2003-10-29
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2003-10-29
+ :available: 2003-10-29
+ :modified: 2006-11-02
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution;language:French
+
+@language:
+ :document: French
+ :original: English
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2.default/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+:A~ Constitution Debian
+
+:B~ Constitution du Projet Debian (v1.2) [This Document has been Superseded by v1.3]
+
+1~pre [Prefix]-#
+
+Version 1.2 ratifiée le 29 octobre 2003. Remplace la Version 1.1 ratifiée le 21 juin 2003, qui elle même remplace la Version 1.0 ratifiée le 2 décembre 1998.
+
+1~ Introduction
+
+Le Projet Debian est une association d'individus qui ont pris pour cause commune la création d'un système d'exploitation libre.
+
+Ce document décrit la structure organisationnelle pour les prises de décisions formelles dans le Projet. Il ne décrit pas les buts du Projet ni comment il les atteint, ni ne contient aucune règle excepté celles directement relatives au processus de prise de décision.
+
+1~ Corps et individus prenant les décisions
+
+Chaque décision dans le Projet est faite par un ou plus des suivants :
+
+# Les Développeurs, par Résolution Générale ou par vote ;
+
+# Le Chef du Projet ;
+
+# Le Comité Technique et/ou son Président ;
+
+# Le Développeur individuel travaillant sur une certaine tâche ;
+
+# Des Délégués nommés par le Chef du Projet pour des tâches spécifiques ;
+
+# Le Secrétaire du Projet.
+
+La plus grosse partie du reste de ce document esquissera les pouvoirs de ces corps, leur composition et leur nomination, et les procédures de leurs prises de décisions. Les pouvoirs d'une personne ou d'un corps peuvent être sujet à révision et/ou limitation par d'autres; dans ce cas le passage concernant le corps ou la personne pouvant faire la révision l'indiquera. Dans la liste ci dessus, une personne ou un corps est habituellement cité avant les personnes ou les corps dont ils peuvent outrepasser les décisions ou qu'ils nomment (ou aident à nommer) - mais ceux qui sont cités avant ne peuvent pas tous outrepasser les décisions de tous ceux qui sont cités ensuite.
+
+2~ Règles Générales
+
+# Rien dans cette constitution n'impose à quiconque d'obligation de faire un travail pour le Projet. Une personne qui ne veut pas faire une tâche qui lui a été déléguée ou assignée n'a pas à la faire. Cependant, elle ne doit pas travailler activement contre ces règles et les décisions prises convenablement qui en découlent.
+
+# Une personne peut cumuler plusieurs postes, excepté le fait que le Chef du Projet, le Secrétaire du Projet et le Président du Comité Technique doivent être distincts, et que le Chef ne peut pas les nommer pour être leurs propres Délégués.
+
+# Une personne peut quitter le Projet ou démissionner d'un poste particulier qu'elle tient, à n'importe quel moment, en le disant publiquement.
+
+1~ Les Développeurs Individuels
+
+2~ Pouvoirs
+
+Un Développeur individuel peut
+
+# prendre n'importe quelle décision technique ou non technique en rapport avec son propre travail ;
+
+# proposer ou soutenir des projets de Résolutions Générales ;
+
+# se proposer lui même comme candidat pour les élections au poste de Chef du Projet ;
+
+# voter les Résolutions Générales et lors des élections au poste de Chef du Projet.
+
+2~ Composition et nomination
+
+# Les développeurs sont des volontaires qui s'accordent à poursuivre les buts du Projet en ce qu'ils y participent, et qui maintiennent des paquets pour le Projet ou font tout autre travail que les Délégués du Chef du Projet considèrent utile.
+
+# Les Délégués du Chef du Projet peuvent choisir de ne pas admettre de nouveaux Développeurs, ou d'expulser des Développeurs existant. Si les Développeurs pensent que les Délégués abusent de leur autorité ils peuvent bien sûr outrepasser la décision par Résolution Générale - voir §4.1(3), §4.2.
+
+2~ Procédure
+
+Les Développeurs peuvent prendre ces décisions comme ils le souhaitent.
+
+1~ Les Développeurs par Résolution Générale ou élection
+
+2~ Pouvoirs
+
+Ensemble, les Développeurs peuvent :
+
+# Nommer ou rétrograder le Chef du Projet.
+
+# Amender cette constitution, pourvu qu'ils soient d'accord avec une majorité de 3 contre 1.
+
+# Outrepasser n'importe quelle décision du Chef du Projet ou d'un Délégué.
+
+# Outrepasser n'importe quelle décision du Comité Technique, pourvu qu'ils soient d'accord avec une majorité de 2 contre 1.
+
+# Produire, mettre à jour ou retirer des déclarations ou des documents régulateurs non techniques.
+
+Ceci inclut des documents décrivant les buts du projet, ses relations avec d'autres entités du logiciel libre, et des règles non techniques comme les termes de la licence de logiciel libre que les logiciels Debian doivent satisfaire.
+
+Cela peut aussi inclure des déclarations de position concernant les problèmes du jour.
+
+_# Un document fondateur (« Foundation Document ») est un document ou une déclaration considéré comme critique pour la mission ou les objectifs du Projet.
+
+_# Les documents fondateurs sont les travaux appelés Contrat social Debian (« Debian Social Contract ») et Directives Debian pour le logiciel libre (« Debian Free Software Guidelines »).
+
+_# Il est nécessaire d'avoir une majorité de 3:1 pour mettre à jour un document fondateur. Les nouveaux documents fondateurs sont produits et les documents fondateurs existants sont retirés, en amendant la liste des documents fondateurs dans cette constitution.
+
+# Ensemble avec le Chef du Projet et SPI, prendre des décisions à propos des biens mis en commun pour les besoins de Debian. (Voir §9.1.)
+
+2~ Procédure
+
+# Les Développeurs suivent la Procédure Standard de Résolution, ci dessous. Une résolution ou un amendement est introduit si il est proposé par n'importe quel Développeur et soutenu par au moins K autres Développeurs, ou si il est proposé par le Chef du Projet ou le Comité Technique.
+
+# Retarder une décision du Chef du Projet ou d'un Délégué :
+
+_# Si le Chef du Projet ou son Délégué, ou le Comité Technique, a pris une décision, alors les Développeurs peuvent l'outrepasser en adoptant une résolution pour cela ; voir s4.1(3).
+
+_# Si une telle résolution est soutenue par au moins 2K Développeurs, ou si elle est proposée par le Comité Technique, la résolution suspend la décision immédiatement (pourvu que la résolution elle même le demande).
+
+_# Si la décision originale était de changer la période de discussion ou de vote, ou si la résolution est d'outrepasser le Comité Technique, alors seulement K Développeurs doivent soutenir la résolution pour pouvoir suspendre immédiatement la décision.
+
+_# Si la décision est suspendue, un vote immédiat est tenu pour déterminer si la décision sera applicable jusqu'à ce que le vote complet sur la décision soit fait ou si l'implémentation de la décision originale sera retardée jusqu'à ce moment. Il n'y a pas de quorum pour ce vote procédural immédiat.
+
+_# Si le Chef du Projet (ou le Délégué) retire la décision originale, le vote devient inutile, et n'est plus poursuivi.
+
+# Les votes sont reçus par le Secrétaire du Projet. Les votes, les contrôles et les résultats ne doivent pas être révélés pendant la durée du scrutin ; après le scrutin, le Secrétaire du Projet liste tous les contenus des votes. La durée du scrutin est de 2 semaines, mais elle peut être modifiée d'au plus une semaine par le Chef du Projet.
+
+# La période de discussion minimum est de 2 semaines, mais elle peut être modifiée d'au plus une semaine par le Chef du Projet. Le Chef du Projet a un vote discriminant. Il y a un quorum de 3Q.
+
+# Les propositions, soutiens, amendements, appels au vote et autres actions formelles sont faites par annonces sur une liste de discussion électronique à lecture publique désignée par le Délégué du Chef du Projet; n'importe quel Développeur peut poster sur celle-ci.
+
+# Les votes sont envoyés par courrier électronique d'une façon qui convienne au Secrétaire. Le Secrétaire détermine pour chaque scrutin si les votants peuvent changer leurs votes.
+
+# Q est la moitié de la racine carré du nombre de Développeurs courant. K est le minimum de Q et de 5. Q et K ne sont pas forcément entiers et ne sont pas arrondis.
+
+1~ Le Chef du Projet
+
+2~ Pouvoirs
+
+Le Chef du Projet peut :
+
+# Nommer des Délégués ou déléguer des décisions au Comité Technique.
+
+Le Chef peut définir un domaine de responsabilité ou une décision courante spécifique et la confier à un autre Développeur ou au Comité Technique.
+
+Une fois qu'une décision particulière a été déléguée et faite, le Chef du Projet ne peut retirer cette délégation ; cependant, il peut retirer une délégation courante d'une aire de responsabilité particulière.
+
+# Prêter de l'autorité à d'autres Développeurs.
+
+Le Chef de Projet peut faire des déclarations de soutien à des points de vue ou à d'autres membres du projet, que cela lui soit demandé ou non ; ces déclarations ont du poids si et seulement si le Chef a le pouvoir de prendre la décision en question.
+
+# Prendre n'importe quelle décision qui demande une action urgente.
+
+Cela ne s'applique pas aux décisions qui sont seulement devenues graduellement urgente à cause d'un manque d'action significative, sauf s'il y a une date butoir.
+
+# Prendre n'importe quelle décision pour laquelle personne d'autre n'a de responsabilité.
+
+# Proposer des Résolutions Générales et des amendements.
+
+# Ensemble avec le Comité Technique, nommer de nouveaux membres au Comité. (Voir §6.2.)
+
+# Utiliser un vote discriminant quand les Développeurs votent.
+
+Le Chef de Projet a aussi un vote normal dans ces scrutins.
+
+# Changer la période de discussion des vote des Développeurs (comme ci-dessus).
+
+# Mener les discussions parmi les Développeurs.
+
+Le Chef de Projet devrait essayer de participer aux discussions parmi les Développeurs d'une manière utile qui cherche à amener la discussion à traiter des problèmes clés en suspend. Le Chef de Projet ne devrait pas utiliser sa position d'autorité pour promouvoir ses vues personnelles.
+
+# Ensemble avec SPI, prendre les décisions affectant les biens possédés en commun pour les besoins relatifs à Debian. (Voir §9.1.)
+
+2~ Nomination
+
+# Le Chef de Projet est élu par les Développeurs.
+
+# Une élection commence neuf semaines avant que le poste de chef ne devienne vacant, ou (si c'est déjà trop tard) immédiatement.
+
+# Pendant les trois semaines suivantes n'importe quel Développeur peut se porter candidat au poste de Chef du Projet.
+
+# Pendant les trois semaines suivantes, aucun candidat ne peut plus se présenter ; les candidats devraient utiliser cette période pour faire campagne (pour faire connaître leurs identités et leurs positions). S'il n'y a pas de candidats à la fin de la période de désignation alors cette période est étendue de trois semaines supplémentaires, répétitivement si nécessaire.
+
+# Les trois semaines suivantes sont la période de scrutin pendant laquelle les Développeurs peuvent envoyer leurs votes. Les votes de l'élection du chef sont tenus secrets, même après que l'élection est finie.
+
+# Les choix possibles sur les bulletins seront les candidats qui se sont désignés et qui ne se sont pas encore retirés, plus le choix « None Of The Above » (Aucun de ceux qui précèdent). Si le choix « None Of The Above » gagne l'élection alors la procédure d'élection est recommencée, plusieurs fois si nécessaire.
+
+# La décision sera prise en utilisant la méthode spécifiée dans la section §A.6 de la Procédure de Résolution Standard. Le quorum est le même que pour une Résolution Générale (§4.2) et l'option par défaut est « None Of The Above ».
+
+# Le Chef du Projet est désigné pour une année à compter de son élection.
+
+2~ Procédure
+
+Le Chef du Projet devrait essayer de prendre des décisions qui sont consistantes avec le consensus d'opinions des Développeurs.
+
+Lorsque c'est possible le Chef du Projet devrait solliciter de manière informelle les opinions des Développeurs.
+
+Le Chef du Projet devrait éviter de trop souligner son propre point de vue quand il s'agit de prendre des décisions qui relèvent de ses attributions de Chef.
+
+1~ Comité Technique
+
+2~ Pouvoirs
+
+Le Comité Technique peut :
+
+# Décider sur n'importe quel sujet concernant les règles techniques.
+
+Cela inclut le contenu des manuels de règles techniques, des documents de référence pour les développeurs, des paquets exemples et le comportement des outils non expérimentaux de création de paquets (dans chaque cas, le responsable du logiciel concerné ou de la documentation prend les décisions initialement, cependant ; voir 6.3(5)).
+
+# Décider sur n'importe quel sujet technique où les juridictions des Développeurs se recouvrent.
+
+Dans les cas où les Développeurs ont besoin d'implémenter des règles techniques compatibles ou des décisions (par exemple, s'ils ne sont pas d'accord sur les priorités de paquets en conflit, ou pour attribuer la propriété d'un nom de commande, ou pour déterminer quel paquet est responsable d'un bogue que les deux responsables reconnaissent être un bogue, ou pour désigner le responsable d'un paquet), le Comité Technique peut décider sur le sujet.
+
+# Prendre une décision quand on le lui demande.
+
+Une personne ou un corps peut déléguer une décision de son ressort au Comité Technique, ou chercher conseil auprès de lui.
+
+# Outrepasser un Développeur (demande une majorité de 3 contre 1).
+
+Le Comité Technique peut demander à un Développeur de choisir une solution technique particulière même si le Développeur ne le souhaite pas ; cela demande une majorité de 3 contre 1. Par exemple, le Comité peut décider qu'une complainte faite par une personne soumettant un bogue est justifiée et que la solution proposée par celui qui soumet le bogue devrait être implémentée.
+
+# Offrir conseil.
+
+Le Comité Technique peut faire des annonces formelles à propos de ses vues sur n'importe quel sujet. Les membres individuels peuvent bien sûr faire des déclarations informelles à propos de leurs vues et à propos des vues probables du comité.
+
+# Ensemble avec le Chef du Projet, nommer de nouveaux membres en son sein ou en retirer. (Voir §6.2.)
+
+# Nommer le Président du Comité Technique.
+
+Le Président est élu par le Comité à partir de ses membres. Tous les membres du Comité sont automatiquement nommés ; le Comité vote en commençant une semaine avant que le poste ne devienne vacant (ou immédiatement, si c'est déjà trop tard). Les membres peuvent voter par acclamation publique pour n'importe quel membre du Comité, y compris eux-même ; il n'y a pas de choix par défaut. Le vote se termine lorsque tous les membres ont voté ou quand la période du scrutin se termine. Le résultat est déterminé en utilisant la méthode décrite dans la section A.6 de la Procédure standard de résolution.
+
+# Le Président peut représenter le Chef, ensemble avec le Secrétaire.
+
+Comme détaillé dans §7.1(2), le Président du Comité Technique et le Secrétaire du Projet peuvent ensemble représenter le Chef s'il n'y a pas de Chef.
+
+2~ Composition
+
+# Le Comité Technique est constitué d'au plus 8 Développeurs, et devrait normalement avoir au moins 4 membres.
+
+# Quand il y a moins de 8 membres le Comité Technique peut recommander un nouveau membre (ou plus) au Chef du Projet, qui peut choisir (individuellement) de les nommer ou pas.
+
+# Quand il y a 5 membres ou moins, le Comité Technique peut nommer de nouveaux membres jusqu'à ce que le nombre de membres atteigne 6.
+
+# Quand il y a eu 5 membres ou moins pendant au moins une semaine, le Chef du Projet peut nommer de nouveaux membres jusqu'à ce que le nombre de membres atteigne 6, à intervalles d'au moins une semaine par nomination.
+
+# Si le Comité Technique et le Chef du Projet sont d'accord ils peuvent retirer ou remplacer un membre existant du Comité Technique.
+
+2~ Procédure
+
+# Le Comité Technique utilise la Procédure Standard de Résolution.
+
+Une proposition de résolution ou un amendement peut être proposé par n'importe quel membre du Comité Technique. Il n'y a pas de période de discussion minimum ; la période de vote dure jusqu'à une semaine, ou jusqu'à ce que le résultat ne fasse plus de doute. Les membres peuvent modifier leurs votes. Il y a un quorum de deux.
+
+# Détails concernant le vote.
+
+Le Président a une voix discriminante. Lorsque le Comité Technique vote pour outrepasser un Développeur qui est aussi un membre du Comité, ce membre ne peut pas voter (sauf s'il s'agit du Président, auquel cas il peut utiliser seulement sa voix discriminante).
+
+# Discussion publique et prise de décision.
+
+Les discussions, propositions de résolutions et amendements, et votes par les membres du Comité, sont rendus publics sur la liste de discussion du Comité Technique. Il n'y a pas de secrétariat séparé pour le Comité.
+
+# Confidentialité des nominations.
+
+Le Comité Technique peut rendre confidentielles les discussions par courrier électronique privé ou par liste de diffusion privée ou d'autres moyens afin de discuter les nominations au Comité. Cependant, les votes des nominations doivent être publics.
+
+# Pas de travail de conception détaillé.
+
+Le Comité Technique ne s'engage pas dans la conception de nouvelles propositions et de nouvelles règles. Ce travail de conception doit être mené par les individus de manière privée ou ensemble et discuté dans des forums techniques ordinaires de conception et de choix d'implémentation.
+
+Le Comité Technique se restreint à choisir ou adopter des compromis entre les solutions et décisions qui ont été proposées et suffisamment bien discutées ailleurs.
+
+Les membres individuels du Comité Technique peuvent bien sûr participer en leur propre nom à tous les aspects du travail de conception et de choix d'implémentation.
+
+# Le Comité Technique prend les décisions uniquement en dernier ressort.
+
+Le Comité Technique ne prend pas de décision technique tant que des efforts de résolution par consensus n'ont pas été menés et n'ont pas échoué sauf s'il lui a été demandé de prendre la décision par la personne ou le corps qui en serait normalement responsable.
+
+1~ Le Secrétaire du Projet
+
+2~ Pouvoirs
+
+Le Secrétaire :
+
+# Reçoit les votes des Développeurs, et détermine le nombre et l'identité des Développeurs, quand c'est requis par la constitution.
+
+# Peut représenter le Chef, avec le Président du Comité Technique.
+
+S'il n'y a pas de Chef du Projet alors le Président du Comité Technique et le Secrétaire du Projet peuvent par accord mutuel prendre des décisions s'ils considèrent comme impératif de le faire.
+
+# Résout les divergences d'interprétation de la constitution.
+
+# Peut déléguer une part ou toute son autorité à quelqu'un d'autre, ou retirer une telle délégation à tout moment.
+
+2~ Nomination
+
+Le Secrétaire du Projet est nommé par le Chef du Projet et le Secrétaire du Projet courant.
+
+Si le Chef du Projet et le Secrétaire du Projet courant ne peuvent se mettre d'accord sur une nouvelle nomination, ils doivent demander au conseil d'administration de SPI (voir §9.1.) de nommer un Secrétaire.
+
+S'il n'y a pas de Secrétaire du Projet ou si le Secrétaire courant n'est pas disponible et n'a pas délégué d'autorité pour une décision alors la décision peut être faite ou déléguée par le Président du Comité Technique, en tant que Secrétaire en Acte.
+
+La durée du mandat de Secrétaire du Projet est de un an, à la suite duquel lui ou un autre Secrétaire doit être (re)nommé.
+
+2~ Procédure
+
+Le Secrétaire du Projet devrait prendre des décisions justes et raisonnables, et de préférence en accord avec le consensus des Développeurs.
+
+Quand ils agissent ensemble pour représenter un Chef du Projet absent, le Président du Comité Technique et le Secrétaire du Projet devraient prendre des décisions seulement quand c'est absolument nécessaire et seulement en accord avec le consensus des Développeurs.
+
+1~ Les Délégués du Chef du Projet
+
+2~ Pouvoirs
+
+Les Délégués du Chef du Projet :
+
+# ont les pouvoirs qui leurs sont délégués par le Chef du Projet ;
+
+# peuvent prendre certaines décisions que le Chef ne peut prendre directement, y compris approuver ou expulser des Développeurs ou désigner des gens comme Développeurs qui ne maintiennent pas de paquets. C'est pour éviter la concentration des pouvoirs, particulièrement au sujet de la qualité de Développeur, dans les mains du Chef du Projet.
+
+2~ Nomination
+
+Les Délégués sont nommés par le Chef du Projet et peuvent être remplacés par le Chef à sa discrétion. Le Chef du Projet ne peut rendre le poste de Délégué conditionnel à des décisions particulières du Délégué, ni outrepasser une décision prise par un Délégué une fois prise.
+
+2~ Procédure
+
+Les Délégués peuvent prendre les décisions selon leur convenance, mais devraient essayer d'implémenter de bonnes décisions techniques et/ou suivre l'opinion consensuelle.
+
+1~ Software in the Public Interest
+
+SPI et Debian sont des organisations séparées qui partagent certains buts. Debian remercie SPI pour le support légal offert par cette organisation.Les Développeurs Debian sont des membres courants de SPI de par leur status de Développeurs.
+
+2~ Autorité
+
+# SPI n'a pas d'autorité concernant les décisions techniques ou non techniques de Debian, excepté que toute décision de Debian concernant tous les biens gardés par SPI nécessite que SPI agisse en dehors de son autorité légale, et que la constitution de Debian peut occasionnellement utiliser SPI comme un corps de décision en dernier ressort.
+
+# Debian ne revendique aucune autorité sur SPI autre que l'utilisation de certains biens de SPI, comme décrit ci dessous, bien que les Développeurs Debian peuvent recevoir des responsabilité à l'intérieur de SPI suivant les règles de SPI.
+
+# Les Développeurs Debian ne sont pas des agents ou des employés ni de SPI, ni les uns des autres, ni de personnes ayant des responsabilités dans le Projet Debian. Une personne agissant en tant que Développeur le fait en tant qu'individu, de son propre chef.
+
+2~ Gestion des biens pour les besoins de Debian
+
+Comme Debian n'a pas d'autorité légale pour garder de l'argent ou des biens, tous les dons pour le Projet Debian doivent être faits à SPI, qui gère ce type d'affaires.
+
+SPI a pris les engagements suivants :
+
+# SPI gardera l'argent, les marques commerciales et les autres biens tangibles et intangibles et gérera des affaires pour les besoins de Debian ;
+
+# Ces biens seront comptabilisés séparément et gardés en commun pour ces besoins, les décisions les concernant seront prises par Debian et SPI conformément à cette section ;
+
+# SPI n'utilisera pas et ne disposera pas de ces biens gardés en commun pour Debian sans l'approbation de Debian, qui peut être fournie par le Chef du Projet ou par Résolution Générale des Développeurs ;
+
+# SPI pourra utiliser et disposer de ces biens gardés en commun pour Debian quand cela lui sera demandé par le Chef du Projet ;
+
+# SPI utilisera et disposera de ces biens gardés en commun pour Debian quand cela lui sera demandé par Résolution Générale des Développeurs, pourvu que cela soit compatible avec l'autorité légale de SPI ;
+
+# SPI informera les Développeurs par courrier électronique sur la liste de diffusion du Projet Debian quand il utilisera ou disposera des biens gardés en commun pour Debian.
+
+1~a A. Procédure de Résolution Standard
+
+Ces règles s'appliquent aux prises de décision communes par comités et plébiscites, là où cela est indiqué plus haut.
+
+2~a1a A.1. Proposition
+
+La procédure formelle commence quand un projet de résolution est proposé et soutenu, comme il est requis.
+
+2~a1a A.1. Discussion et Amendements
+
+# Après la proposition, la résolution peut être discutée. Les amendements peuvent être rendus formels en étant proposés et soutenus conformément aux exigences d'une nouvelle résolution, ou directement par celui qui a proposé la résolution originale.
+
+# Un amendement formel peut être accepté par celui qui propose la résolution, dans ce cas la proposition de résolution formelle est immédiatement modifiée pour s'y accorder.
+
+# Si un amendement formel n'est pas accepté, ou si l'un de ceux qui soutiennent la résolution n'est pas d'accord avec l'acceptation d'un amendement formel par celui qui propose la résolution, l'amendement reste un amendement et sera mis au vote.
+
+# Si un amendement accepté par celui qui a originellement proposé la résolution n'est pas du goût d'autres développeurs, ils peuvent proposer un autre amendement pour inverser les changements précédents (de même, ils doivent satisfaire aux exigences relatives à celui qui le propose et ceux qui le soutiennent).
+
+# Celui qui propose la résolution ou la résolution elle-même peuvent suggérer des modifications à la rédaction des amendements ; ils prennent effet si celui qui propose un amendement est d'accord et si aucun de ceux qui le soutiennent ne s'y oppose. Dans ce cas les amendements modifiés seront votés à la place des amendements originaux.
+
+# Celui qui propose une résolution peut faire des modifications pour corriger des erreurs mineures (par exemple, des erreurs typographiques ou des inconsistances) ou changements qui n'en modifient pas la signification, pourvu que personne ne s'y oppose dans les 24 heures. Dans ce cas la période de discussion minimum n'est pas recommencée.
+
+2~a2 A.2. Appel à voter
+
+# Celui qui propose ou l'un de ceux qui soutiennent une motion ou un amendement peuvent appeler à voter, pourvu que la période de discussion minimum (s'il y en a) soit terminée.
+
+# Celui qui propose ou l'un de ceux qui soutiennent une résolution peuvent appeler à voter sur cette résolution et tous les amendements liés.
+
+# La personne qui appelle à voter déclare ce qu'elle croît devoir être la formulation de la résolution et des amendements liés, et en conséquence ce que la forme du bulletin doit être. Cependant, la décision finale sur la forme du ou des bulletins est celle du Secrétaire - voir 7.1(1), 7.1(3) et A.3(4).
+
+# La période de discussion minimum est comptée à partir du moment où le dernier amendement formel a été accepté, ou à partir du moment où l'entière résolution a été proposée si aucun amendement n'a été proposé et accepté.
+
+2~a3 A.3. Procédure de vote
+
+# Chaque résolution et les amendements qui lui sont liés sont soumis aux votes en un seul scrutin qui contient une option pour la résolution originale, pour chaque amendement, et pour l'option par défaut (quand elle s'applique).
+
+# L'option par défaut ne doit nécessiter aucune supermajorité. Les options qui ne nécessitent pas de supermajorité ont besoin d'une majorité de 1:1 pour être adoptés.
+
+# Les votes sont comptabilisés suivant les règles de A.6. L'option par défaut est « Further Discussion » (Discussion prolongée), sauf en cas de spécification contraire.
+
+# En cas de doutes le Secrétaire du Projet devra décider sur les questions de procédure.
+
+2~a4 A.4. Retrait des résolutions et des amendements non encore acceptés
+
+Celui qui propose une résolution ou un amendement non encore accepté peut le retirer. Dans ce cas certains peuvent vouloir le (ou la) garder, auquel cas la première personne qui souhaite le (ou la) garder devient celui qui le (ou la) propose et les autres soutiennent alors si ce n'est pas déjà le cas.
+
+Ceux qui soutiennent une résolution ou un amendement (sauf s'il a été accepté) peuvent se retirer.
+
+Si le retrait de celui qui propose et/ou de ceux qui soutiennent implique qu'une résolution ou un amendement ne soit plus proposée ou n'ai pas assez de personne qui la soutienne elle ne sera pas voté sauf si cela est rectifié avant que la résolution expire.
+
+2~a5 A.5. Expiration
+
+Si une résolution proposée n'a pas été discutée, amendée, votée ou traitée d'une façon ou d'une autre pendant 4 semaines, le Secrétaire peut décréter que la résolution est retirée. Si aucun de ceux qui soutiennent l'une des propositions ne manifeste son désaccord pendant une semaine, la résolution est retirée.
+
+Le Secrétaire peut aussi suggérer des façons de procéder, si besoin.
+
+2~a6 A.6. Comptabilisation des Votes
+
+# Chaque bulletin de vote classe les options soumises au vote. Il n'est pas nécessaire que toutes les options apparaissent dans le classement. Les options apparaissant dans le classement sont considérées comme préférées à toutes celles qui n'y apparaissent pas. Les votants peuvent classer à égalité plusieurs options. Les options non classées sont considérées comme étant à égalité les unes avec les autres. Les détails sur la façon dont les bulletins doivent être remplis seront contenus dans l'appel à voter.
+
+# Si le scrutin nécessite un quorum R, toute option autre que celle par défaut, qui ne reçoit pas au moins R votes qui la classent au dessus de l'option par défaut, est ignorée.
+
+# Toute option (autre que celle par défaut), qui ne bat pas l'option par défaut avec un rapport au moins égal à celui de la majorité requise, est ignorée.
+
+_# Étant donné deux options A et B, V(A,B) est le nombre de votants préférant l'option A à l'option B.
+
+_# Une option A bat l'option par défaut D avec un rapport de majorité N, si V(A,D) est strictement supérieur à N * V(D,A).
+
+_# Si une supermajorité de S:1 est nécessaire pour A, son rapport de majorité est S; sinon, il est égal à 1.
+
+# À partir de la liste des options non ignorées, nous générons une liste des vainqueurs deux à deux.
+
+_# Une option A bat une option B, si V(A,B) est strictement supérieur à V(B,A).
+
+# À partir de la liste des vainqueurs [non-ignorés] deux à deux, nous générons un ensemble des vainqueurs transitifs.
+
+_# Une option A bat transitivement une option C si A bat C ou s'il y a une autre option B telle que A bat B ET B bat transitivement C.
+
+# Nous construisons l'ensemble de Schwartz à partir de l'ensemble des vainqueurs transitif.
+
+_# Une option A est dans l'ensemble de Schwartz si pour toutes les options B, soit A bat transitivement B, soit B ne bat pas transitivement A.
+
+# S'il y a des options qui en battent d'autres dans l'ensemble de Schwartz, nous sortons les plus faibles des vainqueurs de la liste des vainqueurs deux à deux, et retournons à l'étape 5.
+
+_# Une victoire (A,X) est plus faible qu'une victoire (B,Y) si V(A,X) est inférieur à V(B,Y). Et de plus, (A,X) est plus faible que (B,Y) si V(A,X) est égal à V(B,Y) et V(X,A) est plus grand que V(Y,B).
+
+_# Une plus faible victoire est une victoire qui n'a pas de victoire plus faible qu'elle. Il peut y avoir plusieurs victoires de ce type.
+
+# S'il n'y a pas de plus faible dans l'ensemble de Schwartz set, alors le vainqueur est choisi dans l'ensemble de Schwartz set. S'il n'y a qu'une seule option, c'est le vainqueur. S'il y en a plusieurs, le votant ayant un vote discriminant choisi l'option qui gagne parmi celles-ci.
+
+Note : Les options que les votants classent au dessus de l'option par défaut sont celles qu'ils trouvent acceptables. Les options classées en dessous de l'option par défaut sont les options qu'ils trouvent inacceptables.
+
+Quand la Procédure de Résolution Standard est utilisée, le texte qui y fait référence doit spécifier ce qui est suffisant pour qu'une proposition de résolution soit proposée et/ou soutenue, ce qu'est la période de discussion minimum, et ce qu'est la période de vote. Il doit aussi spécifier quelle supermajorité et/ou le quorum (et le choix par défaut) à utiliser.
+
+1~b B. Utilisation du langage et typographie
+
+Le présent ou le futur de l'indicatif (« est » ou « sera », par exemple) signifie que l'affirmation est une règle dans cette constitution. Le verbe « Pouvoir » indique que la personne ou le corps a le choix. Le verbe « Devoir » au conditionnel indique que cela serait considéré comme une bonne chose si ce qui prescrit était respecté, mais cela n'est pas obligatoire. Le texte marqué comme une citation, comme celui ci, se veut simplement raisonnable et ne fait pas partie de la constitution. Il peut être utilisé seulement pour aider à l'interprétation en cas de doute.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.3.adjusted.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.3.adjusted.sst
new file mode 100644
index 00000000..51a047b8
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.3.adjusted.sst
@@ -0,0 +1,506 @@
+% SiSU 2.0
+
+% Last Modified: Tue, Nov 14 15:39:52 UTC 2006
+% Copyright © 1997-2006 SPI; See license terms
+% Debian is a registered trademark of Software in the Public Interest, Inc.
+
+@title: Debian Constitution
+ :subtitle: Constitution for the Debian Project
+ :edition: v1.3
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution
+
+@date:
+ :published: 2006-09-24
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2006-09-24
+ :available: 2006-09-24
+ :modified: 2006-11-14
+
+@language:
+ :document: English
+ :original: English
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license <br>"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc.
+ :license: This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {Debian Project}http://www.debian.org/
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Site map}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up as a SiSU sample document.<br>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.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.3.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+:A~ Debian Constitution
+
+:B~ Constitution for the Debian Project (v1.3)
+
+1~pre [Prefix]-#
+
+{Version 1.3}http://www.debian.org/devel/constitution.1.3 ratified on September 24th, 2006. Supersedes {Version 1.2}http://www.debian.org/devel/constitution.1.2 ratified on October 29th, 2003 and {Version 1.1}http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes {Version 1.0}http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.
+
+1~ 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.
+
+1~ 2. Decision-making bodies and individuals
+
+Each decision in the Project is made by one or more of the following:
+
+_1 1. The Developers, by way of General Resolution or an election;
+
+_1 2. The Project Leader;
+
+_1 3. The Technical Committee and/or its Chairman;
+
+_1 4. The individual Developer working on a particular task;
+
+_1 5. Delegates appointed by the Project Leader for specific tasks;
+
+_1 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~ 2.1. General rules
+
+_1 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.
+
+_1 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.
+
+_1 3. A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly.
+
+1~ 3. Individual Developers
+
+2~ 3.1. Powers
+
+An individual Developer may
+
+_1 1. make any technical or nontechnical decision with regard to their own work;
+
+_1 2. propose or sponsor draft General Resolutions;
+
+_1 3. propose themselves as a Project Leader candidate in elections;
+
+_1 4. vote on General Resolutions and in Leadership elections.
+
+2~ 3.2. Composition and appointment
+
+_1 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.
+
+_1 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.
+
+2~ 3.3. Procedure
+
+Developers may make these decisions as they see fit.
+
+1~ 4. The Developers by way of General Resolution or election
+
+2~ 4.1. Powers
+
+Together, the Developers may:
+
+_1 1. Appoint or recall the Project Leader.
+
+_1 2. Amend this constitution, provided they agree with a 3:1 majority.
+
+_1 3. Make or override any decision authorised by the powers of the Project Leader or a Delegate.
+
+_1 4. Make or override any decision authorised by the powers of the Technical Committee, provided they agree with a 2:1 majority.
+
+_1 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.
+
+_2 1. A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes.
+
+_2 2. The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines.
+
+_2 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.
+
+_1 6. Make decisions about property held in trust for purposes related to Debian. (See §9.).
+
+_1 7. In case of a disagreement between the project leader and the incumbent secretary, appoint a new secretary.
+
+2~ 4.2. Procedure
+
+_1 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.
+
+_1 2. Delaying a decision by the Project Leader or their Delegate:
+
+_2 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 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).
+
+_2 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.
+
+_2 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.
+
+_2 5. If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+1~ 5. Project Leader
+
+2~ 5.1. Powers
+
+The {Project Leader}http://www.debian.org/devel/leader may:
+
+_1 1. Appoint Delegates or delegate decisions to the Technical Committee.
+
+_1 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.
+
+_1 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.
+
+_1 2. Lend authority to other Developers.
+
+_1 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.
+
+_1 3. Make any decision which requires urgent action.
+
+_1 This does not apply to decisions which have only become gradually urgent through lack of relevant action, unless there is a fixed deadline.
+
+_1 4. Make any decision for whom noone else has responsibility.
+
+_1 5. Propose draft General Resolutions and amendments.
+
+_1 6. Together with the Technical Committee, appoint new members to the Committee. (See §6.2.)
+
+_1 7. Use a casting vote when Developers vote.
+
+_1 The Project Leader also has a normal vote in such ballots.
+
+_1 8. Vary the discussion period for Developers' votes (as above).
+
+_1 9. Lead discussions amongst Developers.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+2~ 5.2. Appointment
+
+_1 1. The Project Leader is elected by the Developers.
+
+_1 2. The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately.
+
+_1 3. For the following three weeks any Developer may nominate themselves as a candidate Project Leader.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+_1 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".
+
+_1 8. The Project Leader serves for one year from their election.
+
+2~ 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.
+
+1~ 6. Technical committee
+
+2~ 6.1. Powers
+
+The {Technical Committee}http://www.debian.org/devel/tech-ctte may:
+
+_1 1. Decide on any matter of technical policy.
+
+_1 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).)
+
+_1 2. Decide any technical matter where Developers' jurisdictions overlap.
+
+_1 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.
+
+_1 3. Make a decision when asked to do so.
+
+_1 Any person or body may delegate a decision of their own to the Technical Committee, or seek advice from it.
+
+_1 4. Overrule a Developer (requires a 3:1 majority).
+
+_1 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.
+
+_1 5. Offer advice.
+
+_1 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.
+
+_1 6. Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.)
+
+_1 7. Appoint the Chairman of the Technical Committee.
+
+_1 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.
+
+_1 8. The Chairman can stand in for the Leader, together with the Secretary
+
+_1 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.
+
+2~ 6.2. Composition
+
+_1 1. The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members.
+
+_1 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.
+
+_1 3. When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6.
+
+_1 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.
+
+_1 5. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee.
+
+2~ 6.3. Procedure
+
+_1 1. The Technical Committee uses the Standard Resolution Procedure.
+
+_1 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.
+
+_1 2. Details regarding voting
+
+_1 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).
+
+_1 3. Public discussion and decision-making.
+
+_1 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.
+
+_1 4. Confidentiality of appointments.
+
+_1 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.
+
+_1 5. No detailed design work.
+
+_1 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.
+
+_1 The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere.
+
+_1 Individual members of the technical committee may of course participate on their own behalf in any aspect of design and policy work.
+
+_1 6. Technical Committee makes decisions only as last resort.
+
+_1 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.
+
+1~ 7. The Project Secretary
+
+2~ 7.1. Powers
+
+The {Secretary:}http://www.debian.org/devel/secretary
+
+_1 1. Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution.
+
+_1 2. Can stand in for the Leader, together with the Chairman of the Technical Committee.
+
+_1 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.
+
+_1 3. Adjudicates any disputes about interpretation of the constitution.
+
+_1 4. May delegate part or all of their authority to someone else, or withdraw such a delegation at any time.
+
+2~ 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.
+
+2~ 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.
+
+1~ 8. The Project Leader's Delegates
+
+2~ 8.1. Powers
+
+The Project Leader's Delegates:
+
+_1 1. have powers delegated to them by the Project Leader;
+
+_1 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.
+
+2~ 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.
+
+2~ 8.3. Procedure
+
+Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion.
+
+1~ 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.
+
+2~ 9.1. Relationship with Associated Organizations
+
+_1 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.
+
+2~ 9.2. Authority
+
+_1 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.
+
+_1 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.
+
+2~ 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.
+
+1~a A. Standard Resolution Procedure
+
+These rules apply to communal decision-making by committees and plebiscites, where stated above.
+
+2~a1 A.1. Proposal
+
+The formal procedure begins when a draft resolution is proposed and sponsored, as required.
+
+2~a1a A.1. Discussion and Amendment
+
+_1 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.
+
+_1 2. A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match.
+
+_1 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.
+
+_1 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).)
+
+_1 5. The proposer or 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.
+
+_1 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.
+
+2~a2 A.2. Calling for a vote
+
+_1 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.
+
+_1 2. The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments.
+
+_1 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).
+
+_1 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.
+
+2~a3 A.3. Voting procedure
+
+_1 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).
+
+_1 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.
+
+_1 3. The votes are counted according to the rules in A.6. The default option is "Further Discussion", unless specified otherwise.
+
+_1 4. In cases of doubt the Project Secretary shall decide on matters of procedure.
+
+2~a4 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.
+
+2~a5 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.
+
+2~a6 A.6. Vote Counting
+
+_1 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.
+
+_1 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.
+
+_1 3. Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration.
+
+_2 1. Given two options A and B, V(A,B) is the number of voters who prefer option A over option B.
+
+_2 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).
+
+_2 3. If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1.
+
+_1 4. From the list of undropped options, we generate a list of pairwise defeats.
+
+_2 1. An option A defeats an option B, if V(A,B) is strictly greater than V(B,A).
+
+_1 5. From the list of [undropped] pairwise defeats, we generate a set of transitive defeats.
+
+_2 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.
+
+_1 6. We construct the Schwartz set from the set of transitive defeats.
+
+_2 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.
+
+_1 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.
+
+_2 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 2. A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat.
+
+_1 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. }/
+
+2~b 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.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.3.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.3.sst
new file mode 100644
index 00000000..fdf0d91e
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.3.sst
@@ -0,0 +1,507 @@
+% SiSU 2.0
+
+% Last Modified: Tue, Nov 14 15:39:52 UTC 2006
+% Copyright © 1997-2006 SPI; See license terms
+% Debian is a registered trademark of Software in the Public Interest, Inc.
+
+@title: Debian Constitution
+ :subtitle: Constitution for the Debian Project (v1.3)
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution
+
+@date:
+ :published: 2006-09-24
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2006-09-24
+ :available: 2006-09-24
+ :modified: 2006-11-14
+
+@language:
+ :document: English
+ :original: English
+
+% @italics:
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license <br>"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc.
+ :license: This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {Debian Project}http://www.debian.org/
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Site map}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up as a SiSU sample document.<br>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.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.3.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Debian Constitution
+
+:B~ Constitution for the Debian Project (v1.3)
+
+1~pre [Prefix]-#
+
+{Version 1.3}http://www.debian.org/devel/constitution.1.3 ratified on September 24th, 2006. Supersedes {Version 1.2}http://www.debian.org/devel/constitution.1.2 ratified on October 29th, 2003 and {Version 1.1}http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes {Version 1.0}http://www.debian.org/devel/constitution.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.
+
+1~ Decision-making bodies and individuals
+
+Each decision in the Project is made by one or more of the following:
+
+# The Developers, by way of General Resolution or an election;
+
+# The Project Leader;
+
+# The Technical Committee and/or its Chairman;
+
+# The individual Developer working on a particular task;
+
+# Delegates appointed by the Project Leader for specific tasks;
+
+# 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~ General rules
+
+# 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.
+
+# 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.
+
+# A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly.
+
+1~ Individual Developers
+
+2~ Powers
+
+An individual Developer may
+
+# make any technical or nontechnical decision with regard to their own work;
+
+# propose or sponsor draft General Resolutions;
+
+# propose themselves as a Project Leader candidate in elections;
+
+# vote on General Resolutions and in Leadership elections.
+
+2~ Composition and appointment
+
+# 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.
+
+# 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.
+
+2~ Procedure
+
+Developers may make these decisions as they see fit.
+
+1~ The Developers by way of General Resolution or election
+
+2~ Powers
+
+Together, the Developers may:
+
+# Appoint or recall the Project Leader.
+
+# Amend this constitution, provided they agree with a 3:1 majority.
+
+# Make or override any decision authorised by the powers of the Project Leader or a Delegate.
+
+# Make or override any decision authorised by the powers of the Technical Committee, provided they agree with a 2:1 majority.
+
+# 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.
+
+_# A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes.
+
+_# The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines.
+
+_# 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.
+
+# Make decisions about property held in trust for purposes related to Debian. (See §9.).
+
+# In case of a disagreement between the project leader and the incumbent secretary, appoint a new secretary.
+
+2~ Procedure
+
+# 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.
+
+# Delaying a decision by the Project Leader or their Delegate:
+
+_# 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).
+
+_# 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).
+
+_# 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.
+
+_# 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.
+
+_# If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted.
+
+# 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.
+
+# 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.
+
+# 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.
+
+# Votes are cast by email in a manner suitable to the Secretary. The Secretary determines for each poll whether voters can change their votes.
+
+# 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.
+
+1~ Project Leader
+
+2~ Powers
+
+The {Project Leader}http://www.debian.org/devel/leader may:
+
+# 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.
+
+# 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.
+
+# 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.
+
+# Make any decision for whom noone else has responsibility.
+
+# Propose draft General Resolutions and amendments.
+
+# Together with the Technical Committee, appoint new members to the Committee. (See §6.2.)
+
+# Use a casting vote when Developers vote.
+
+The Project Leader also has a normal vote in such ballots.
+
+# Vary the discussion period for Developers' votes (as above).
+
+# 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.
+
+# 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.
+
+# 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.
+
+2~ Appointment
+
+# The Project Leader is elected by the Developers.
+
+# The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately.
+
+# For the following three weeks any Developer may nominate themselves as a candidate Project Leader.
+
+# 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.
+
+# 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.
+
+# 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.
+
+# 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".
+
+# The Project Leader serves for one year from their election.
+
+2~ 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.
+
+1~ Technical committee
+
+2~ Powers
+
+The {Technical Committee}http://www.debian.org/devel/tech-ctte may:
+
+# 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).)
+
+# 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.
+
+# 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.
+
+# 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.
+
+# 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.
+
+# Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.)
+
+# 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.
+
+# 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.
+
+2~ Composition
+
+# The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members.
+
+# 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.
+
+# When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6.
+
+# 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.
+
+# If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee.
+
+2~ Procedure
+
+# 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.
+
+# 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).
+
+# 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.
+
+# 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.
+
+# 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.}/
+
+# 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.
+
+1~ The Project Secretary
+
+2~ Powers
+
+The {Secretary:}http://www.debian.org/devel/secretary
+
+# Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution.
+
+# 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.
+
+# Adjudicates any disputes about interpretation of the constitution.
+
+# May delegate part or all of their authority to someone else, or withdraw such a delegation at any time.
+
+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.
+
+2~ 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.
+
+1~ The Project Leader's Delegates
+
+2~ Powers
+
+The Project Leader's Delegates:
+
+# have powers delegated to them by the Project Leader;
+
+# 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.
+
+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.
+
+2~ Procedure
+
+Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion.
+
+1~ 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.
+
+2~ Relationship with Associated Organizations
+
+# 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.
+
+2~ Authority
+
+# 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.
+
+# 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.
+
+2~ 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.
+
+1~a A. Standard Resolution Procedure
+
+These rules apply to communal decision-making by committees and plebiscites, where stated above.
+
+2~a1 A.1. Proposal
+
+The formal procedure begins when a draft resolution is proposed and sponsored, as required.
+
+2~a1a A.1 Discussion and Amendment
+
+# 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.
+
+# A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match.
+
+# 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.
+
+# 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).)
+
+# The proposer or 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.
+
+# 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.
+
+2~a2 A.2. Calling for a vote
+
+# 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.
+
+# The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments.
+
+# 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).
+
+# 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.
+
+2~a3 A.3. Voting procedure
+
+# 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).
+
+# The default option must not have any supermajority requirements. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement.
+
+# The votes are counted according to the rules in A.6. The default option is "Further Discussion", unless specified otherwise.
+
+# In cases of doubt the Project Secretary shall decide on matters of procedure.
+
+2~a4 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.
+
+2~a5 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.
+
+2~a6 A.6. Vote Counting
+
+# 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.
+
+# 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.
+
+# Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration.
+
+_# Given two options A and B, V(A,B) is the number of voters who prefer option A over option B.
+
+_# 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).
+
+_# If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1.
+
+# From the list of undropped options, we generate a list of pairwise defeats.
+
+_# An option A defeats an option B, if V(A,B) is strictly greater than V(B,A).
+
+# From the list of [undropped] pairwise defeats, we generate a set of transitive defeats.
+
+_# 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.
+
+# We construct the Schwartz set from the set of transitive defeats.
+
+_# 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.
+
+# 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.
+
+_# 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).
+
+_# A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat.
+
+# 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.}/
+
+1~b 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.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.3~da.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.3~da.sst
new file mode 100644
index 00000000..3ddb7708
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.3~da.sst
@@ -0,0 +1,514 @@
+% SiSU 2.0
+
+@title: Debians vedtægter
+ :subtitle: Debian-projektets vedtægter (v1.3)
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution;language:Danish
+
+@date:
+ :published: 2003-10-29
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2003-10-29
+ :available: 2003-10-29
+ :modified: 2003-10-29
+
+@language:
+ :document: Danish
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.da.html <br>"Debian" og Debians logo http://www.debian.org/logos/ er varemærker tilhørende Software in the Public Interest, Inc.
+ :license: Dette materiale må kun distribueres i henhold til vilkårene beskrevet i Open Publication License, udkast (draft) v1.0 eller senere (du kan læse vores lokale kopi http://www.debian.org/opl, den seneste version er normalt tilgængelig på http://www.opencontent.org/openpub/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.3 blev godkendt den 24. september 2006. Erstatter version 1.2 godkendt den 29. oktober 2003 og version 1.1 godkendt den 21. juni 2003, der erstattede version 1.0 som blev godkendt den 2. december 1998.<br>Dette er en oversættelse af det originale engelsksprogede dokument http://www.debian.org/license.en.html. <br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.3.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Debians vedtægter
+
+:B~ Debian-projektets vedtægter (v1.3)
+
+1~pre [Prefix]-#
+
+{ Version 1.3 }http://www.debian.org/devel/constitution.1.3 blev godkendt den 24. september 2006. Erstatter { version 1.2 }http://www.debian.org/devel/constitution.1.2 godkendt den 29. oktober 2003 og { version 1.1 }http://www.debian.org/devel/constitution.1.1 godkendt den 21. juni 2003, der erstattede { version 1.0 }http://www.debian.org/devel/constitution.1.0 som blev godkendt den 2. december 1998.
+
+1~1 § 1. Introduktion
+
+Debian-projektet er en sammenslutning af personer, som har det fælles mål at udvikle et frit tilgængeligt styresystem.
+
+Dette dokument beskriver organisationsstrukturen for formelle beslutninger i projektet. Det beskriver ikke projektets mål eller hvordan vi opfylder disse, og indeholder ingen retningslinier, bortset fra de retningslinier som direkte vedrører beslutningsprosessen.
+
+1~2 § 2. Beslutningsdygtige organer og -personer
+
+Enhver beslutning i projektet er omfattet af en eller flere af følgende:
+
+# Udviklerne, via en fælles resolution eller et valg;
+
+# Projektlederen;
+
+# Den tekniske komité og/eller dennes formand;
+
+# Den individuelle udvikler som arbejder med en bestemt opgave;
+
+# Delegater udnævnt af projektlederen til at varetage særlige opgaver;
+
+# Projektsekretæren.
+
+Resten af dette dokument vil primært beskrive disse organers fuldmagter, deres sammensætning og udnævnelse, og procedurer for vedtagelser. En persons eller et organs fuldmagt kan i visse tilfælde blive genstand for gennemsyn af andre; i så fald vil det fremgå af afsnittet om det organ, der står for dette. I listen ovenfor er hver person eller hvert organ stort set anført før de personer eller organer de kan (hjælpe til med at) udnævne, og hvis beslutninger de kan ophæve - men ikke alle, der er anført tidligere, kan ophæve beslutninger fortaget af alle som er anført senere.
+
+2~2.1 § 2.1. Generelle regler
+
+# Intet i disse vedtægter forpligter nogen til at arbejde for projeket. En person, der ikke vil udføre en opgave, som er blevet uddelegeret eller pålagt vedkommende, behøver at gøre det. Derimod kan man ikke aktivt modarbejde regler eller beslutninger, som er foretaget korrekt i henhold til reglerne.
+
+# En person kan bestride flere hverv, bortset fra at projektlederen, projektsekretæren og formanden for den tekniske komité skal være forskellige personer, og lederen kan ikke udnæve sig selv, som sin egen delegat.
+
+# En person kan til enhver tid forlade projektet eller fratræde et særskilt hverv vedkommende har, ved offentligt at erklære dette.
+
+1~3 § 3. Individuelle udviklere
+
+2~3.1 § 3.1. Fuldmagt
+
+En individuel udvikler kan
+
+# tage tekniske og ikke-tekniske beslutninger med hensyn til sit eget arbejde;
+
+# foreslå og støtte udkast til generelle resolutioner;
+
+# foreslå sig selv som kandidat til projektleder i valg;
+
+# stemme på generelle resolutioner og i ledervalg.
+
+2~3.2 § 3.2. Sammensætning og udnævnelse
+
+# Udviklere er frivillige som er enige om at fremme projektets mål for så vidt som de deltager i det, og som vedligeholder pakke(r) for projektet eller gør andet arbejde, som projeketlederens delegater anser for værdifuldt.
+
+# Projektlederens delegater kan vælge ikke at optage nye udviklere, eller at ekskludere nuværende udviklere. Hvis udviklerne mener at delegaterne misbruger deres autoritet, kan de selvfølgelig ophæve en beslutning via en generel resolution - se § 4.1(3) og § 4.2.
+
+2~3.3 § 3.3. Fremgangsmåder
+
+Udviklerne kan foretage disse beslutninger efter eget skøn.
+
+1~4 § 4. Udviklerne via generel resolution eller et valg
+
+2~4.1 § 4.1. Fuldmagt
+
+Udviklerne kan sammen:
+
+# Udnævne eller afsætte projektlederen.
+
+# Ændre disse vedtægter med et 3:1-flertal.
+
+# Træffe eller ophæve enhver beslutning autoriseret af projektlederen eller en delegat.
+
+# Træffe eller ophæve enhver beslutning autoriseret af den tekniske komité, såfremt de er enige med et 2:1-flertal.
+
+# Udgive, erstatte og tilbagetrække ikke-tekniske retningslinier og erklæringer.
+
+Dette inkluderer dokumenter som forklarer projektmål, dets forhold til andre organer indenfor fri software, samt ikke-tekniske vejledninger som de fri software-licensbetingelser, som Debians programmel skal leve op til.
+
+Det kan også være stillingtagen til aktuelle emner.
+
+_# Et grundlæggende dokument er et dokument eller en bekendtgørelse, der betragtes som kritisk for projekts arbejde og formål.
+
+_# De grundlæggende dokumenter er det arbejde som er udmundet i Debian sociale kontrake og Debians retningslinier for fri software.
+
+_# Et grundlæggende dokument kræver et 3:1-flertal for dets erstatning. Nye grundlæggende dokumenter udgives og eksisterende dokumenter trækkes tilbage ved at føje til listen over grundlæggende dokumenter i disse vedtægter.
+
+# Træffe beslutninger om forvaltede ejendele til formål med relation til Debian. (Se § 9.1).
+
+# I tilfælde af uenighed mellem projektlederen og den nuværende sekretær, udnævne en ny sekretær.
+
+2~4.2 § 4.2. Fremgangsmåde
+
+# Udviklerne følger de generelle resolutionsprocedurer beskrevet nedenfor. En resolution eller ændring betragtes som introduceret, hvis den er foreslået af en hvilken som helst udvikler og mindst K andre udviklere støtter den, eller hvis den er foreslået af projektlederen eller den tekniske komité.
+
+# Udsættelse af en resolution foretaget af projektlederen eller dennes delegater:
+
+_# Hvis projektlederen, dennes delegater eller den tekniske komité har truffet en beslutning, kan udviklerne ophæve denne ved at vedtage en resolution derom, se § 4.1(3).
+
+_# Hvis en sådan resolution støttes af mindst 2K udviklere eller hvis den er foreslået af den tekniske komité, vil resolutionen omgående tilsidesætte beslutningen (såfremt resolutionen selv siger dette).
+
+_# Hvis den oprindelige beslutning var at ændre en diskussionsperiode eller en stemmeperiode, eller hvis resolutionens formål er at ophæve en beslutning foretaget af den tekniske komité, behøver kun K udviklere at støtte resolutionen, for omgående at kunne tilsidesætte beslutningen.
+
+_# Hvis beslutningen er tilsidesat, holdes omgående en afstemning for at afgøre om beslutningen skal opretholdes indtil en fuldstændig afstemning om beslutningen kan holdes, eller om udførslen af den oprindelige beslutning skal udsættes indtil da. Der findes ikke et beslutningsdygtigt antal stemmer i denne omgående, proceduriske afstemning.
+
+_# Hvis projektlederen (eller dennes delegater) trækker den oprindelige beslutning tilbage, bliver det uaktuelt at holde afstemningen og den vil ikke blive afholdt.
+
+# Stemmer indsamles af projektsekretæren. Stemmerne og afstemningsresultatet offentliggøres ikke i stemmeperioden; efter afstemningen opremser projektsekretæren alle de afgivne stemmer, Afstemningsperioden er to uger, men projektlederen kan tilføje eller fjerne op til en uge.
+
+# Minimumstiden for diskussion er to uger, men projektlederen kan tilføje eller fjerne op til en uge. Projektlederen har den afgørende stemme. Det beslutningsdygtige antals stemmer er 3Q.
+
+# Forslag, støtte, ændringer, stemmeopråb og andre formelle handlinger foregår via erklæringer på en offentlig tilgængelig elektronisk postliste udvalgt af projektlederens delegat(er); alle udviklere har skriveadgang til den.
+
+# Stemmer afgives via e-mail på en måde der bestemmes af sekretæren. Sekretæren bestemmer for hver afstemning hvorvidt vælgerne kan ændre deres stemmer.
+
+# Q er halvdelen af kvadratroden af antallet af udviklere. K er den mindste af Q og 5. Q og K behøver ikke at være heltal, og de afrundes ikke.
+
+1~5 § 5. Projektlederen
+
+2~5.1 § 5.1. Fuldmagt
+
+Projektlederen kan:
+
+# Udnævne delegater eller uddelegere beslutninger til den tekniske komité.
+
+Lederen kan beskrive en opgave med løbende ansvar eller en særskilt beslutning. I begge tilfælde overføres denne til en anden udvikler eller til den tekniske komité.
+
+Efter en særskilt beslutning er blevet uddelegeret og afgjort, kan projektlederen ikke trække uddelegeringen tilbage. derimod kan en løbende uddelegerning til en bestemt opgave trækkes tilbage.
+
+# Give hjemmel til andre udviklere.
+
+Projektlederen kan udgive støtteerklæringer til andres synspunkter eller andre projektmedlemmer, uden at være blevet bedt om det. Disse støtteerklæringer er gyldige, hvis, og kun hvis, lederen ville have haft fuldmagt til at træffe den foreliggende beslutning.
+
+# Foretage beslutninger som kræver omgående handling.
+
+Dette gælder ikke beslutninger som gradvist er blevet påtrængende på grund af manglende, relevant handling, med mindre der er en fastsat frist.
+
+# Foretage beslutninger som ingen andre har ansvaret for.
+
+# Fremstille udkast til generelle resolutioner og ændringsforslag.
+
+# Sammen med den tekniske komité udpege nye medlemmer til komitéen. (Se § 6.2.)
+
+# Afgive en afgørende stemme i udviklernes afstemninger.
+
+Projektlederen har også almindelig stemmeret i sådanne afstemninger.
+
+# Ændre diskussionsperioden for udviklernes afstemninger (som beskrevet ovenfor).
+
+# Lede diskussioner blandt udviklerne.
+
+Projektlederen bør prøve at deltage i diskussioner blandt udviklerne på en hjælpsom måde, som søger at bringe diskussionen på rette kurs mod sagens kerne. Projektlederen bør ikke bruge lederpositionen til at fremme sine egne personlige synspunkter.
+
+# I konsultation med udviklerne, træffe beslutninger der vedrører forvaltede ejendele i forbindelse med Debian. (Se § 9.). Sådanne beslutninger kommunikeres til medlemmerne af projektlederen eller dennes delegat(er). Større udgifter skal foreslås og diskuteres på postlisten før beløbet erlægges.
+
+# Tilføje eller fjerne organisationer fra listen over betroede organisationer (se § 9.3) som er autoriserede til at modtage og være i besiddelse af ejendele for Debian. Evaluering og diskussion førende til sådanne beslutninger finder sted på en elektronisk postliste udpeget af projektlederen eller denne delgat(er), på hvilken alle udviklere må skrive. Der er en minimal diskussionstid på to uger før en organisation må blive føjet til listen over betroede organisationer.
+
+2~5.2 § 5.2. Udnævnelse
+
+# Projektlederen vælges af udviklerne.
+
+# Valget begynder ni uger før lederpositionen bliver ledig eller (hvis det ikke allerede er for sent) omgående.
+
+# I de følgende tre uger kan enhver udvikler nominere sig selv som projektlederkandidat.
+
+# I de efterfølgende tre uger kan der ikke nomineres flere kandidater; kandiaterne bør anvende dette tidsrum til deres valgkamp (for at gøre opmærksom på sig selv og sine synspunkter). Hvis der ikke er nogen kandidater efter nomineringsperioden er slut, bliver perioden udvidet med yderligere tre uger, om nødvendigt gentagne gange.
+
+# De næste tre uger er valgperioden, hvori udviklerene kan stemme. Afstemningen i ledervalg er hemmelig, selv efter afstemningen er afsluttet.
+
+# Valget vil være mellem de kandidater, der har nomineret sig selv og som ikke har trukket sig tilbage, samt Ingen af de nævnte ("None of the Above"). Hvis Ingen af de nævnte vinder valget, bliver denne procedure gentaget, om nødvendigt mange gange.
+
+# Beslutningen træffes ved hjælp af den metode, som er beskrevet i afsnit § A.6 i de generelle resolutionsprocedurer. Det beslutningsdygtige antal er det samme, som ved en generel resolution (§ 4.2), og standardvalget er Ingen af de nævnte.
+
+# Projektlederen vælges for et år ad gangen.
+
+2~5.3 § 5.3. Fremgangsmåde
+
+Projektlederen bør prøve at træffe beslutninger som er i tråd med konsensus blandt udviklerne.
+
+Hvor det er praktisk bør projektlederen på en uformel måde bede om udviklernes synspunkter.
+
+Projektlederen bør undgå at lægge for megen vægt på sine egne synspunkter, når der træffes beslutninger i vedkommendes egenskab af leder.
+
+1~6 § 6. Teknisk komité
+
+2~6.1 § 6.1. Fuldmagt
+
+Den tekniske komité kan:
+
+# Træffe beslutninger om tekniske retningslinier.
+
+Deriblandt også indholdet af de tekniske retningslinier, udviklernes håndbogsmateriale, pakkeeksempler og hvordan ikke-eksperimentelle pakkeopbygningsværktøjer skal fungere. (I hvert tilfælde træffer den almindelige pakkevedligeholder af programmellet eller dokumentationen, de første beslutninger; se § 6.3(5).)
+
+# Afgøre tekniske spørgsmål hvor udviklernes ansvarsområder overlapper.
+
+I tilfælde hvor udviklere skal implementere kompatible tekniske retningslinier eller holdninger (for eksempel hvis de ikke er enige om prioriteringerne ved uforenlige pakker, eller om ejerskab af et kommandonavn, eller om hvilken pakke der er ansvarlig for en fejl som begge pakkevedligeholdere er enige om er en fejl, eller om hvem der bør være vedligeholder af en pakke), kan den tekniske komité afgøre sagen.
+
+# Træffe en beslutning når den bliver bedt om at gøre dette.
+
+Enhver person og ethvert organ kan uddelegere en af sine egne beslutninger til den tekniske komité eller bede om råd fra den.
+
+# Tilsidesætte en udviklers beslutning (kræver et 3:1-flertal)
+
+Den tekniske komité kan bede en udvikler om at benytte en bestemt fremgangsmåde, selvom udvikleren ikke ønsker det; dette kræver et 3:1-flertal. For eksempel kan komitéen komme frem til at en klage fremsat i en fejlrapport er gyldig og at indsenderens foreslåede løsning bør iværksættes.
+
+# Give råd.
+
+Den tekniske komité kan give formelle erklæringer om sit syn på enhvert emne. Individuelle medlemmer kan selvfølgelig give uformelle erklæringer om deres synspunkter og om komitéens sandsynlige synspunkter.
+
+# Sammen med projektlederen udnævne nye medlemmer til sig selv eller fjerne nuværende medlemmer. (Se § 6.2.)
+
+# Udnævne formanden for den tekniske komité.
+
+Komitéen vælger formand blandt sine medlemmer. Medlemmerne af komitéen nomineres automatisk; valget starter en uge før stillingen bliver ledig (eller omgående, hvis det allerede er for sent). Medlemmerne kan stemme via offentlig tilkendegivelse for hvilket som helst komitémedlem, også sig selv. Der er intet standardvalg. Valget afsluttes når alle medlemmerne har stemt eller stemmeperioden er afsluttet. Resultatet afgøres ved hjælp af den metode, som er angivet i § A.6 i de generelle resolutionsprocedurer.
+
+# Formanden kan vikariere for lederen, sammen med sekretæren
+
+Som beskrevet i § 7.1(2), kan formanden for den tekniske komité og projektsekretæren i fællesskab vikariere for lederen, hvis der ikke er en leder.
+
+2~6.2 § 6.2. Sammensætning
+
+# Den tekniske komité består af op til otte udviklere og bør normalt have mindst fire medlemmer.
+
+# Hvis det er mindre end otte medlemmer, kan den tekniske komité anbefale ny(e) medlem(mer) til projektlederen, som (på egen hånd) kan vælge at udnævne dem eller ej.
+
+# Hvis der er fem eller færre medlemmer, kan den tekniske komité udnævne ny(e) medlem(mer) indtil antallet af medlemmer når seks.
+
+# Når der har været fem eller færre medlemmer i mindst en uge, kan projektlederen udnævne nye medlem(mer) indtil antallet af medlemmer når seks, med mindst en uges mellemrum for hver udnævnelse.
+
+# Hvis den tekniske komité og projektlederen er enige kan de fjerne eller erstatte et nuværende medlem af den tekniske komité.
+
+2~6.3 § 6.3. Fremgangsmåde
+
+# Den tekniske komité anvender den generelle resolutionsprocedure.
+
+Et udkast til en resolution eller ændring kan framsættes af ethvert medlem af den tekniske komité. Det er ingen minimumstid for diskussion; valgperioden varer i op til en uge eller indtil der ikke længere kan være nogen tvivl om resultatet. Medlemmerne kan ændre deres stemmer. Det beslutningsdygtige antal er to.
+
+# Detaljerede afstemningoplysninger
+
+Formanden har den afgørende stemme. Når den tekniske komité stemmer for at afgøre, om de skal tilsidesætte en afgørelse taget af en udvikler, der også er et medlem af komitéen, kan dette medlem ikke stemme (med mindre det er formanden, som i dette tilfælde kun kan benytte sin afgørende stemmeret).
+
+# Offentlig diskussion og afgørelser
+
+Diskussioner, udkast til resolutioner og ændringer og komitemedlemmernes stemmer offentliggøres på den tekniske komités offentlige diskussionsliste. Der er ikke en særskilt sekretær for komitéen.
+
+# Fortrolighed ved udnævnelser
+
+Den tekniske komité kan holde fortrolige diskussioner via privat e-mail eller en privat postliste, eller på andre måder diskutere udnævnelser til komitéen. Derimod skal stemmerne ved udnævnelser offentliggøres.
+
+# Ikke et detaljeret udviklingsarbejde
+
+Den tekniske komité giver sig ikke i kast med fremstilling af nye forslag og retningslinier. Sådant udviklingsarbejde bør foretages privat af personer eller grupper, og diskuteres i almindelige tekniske og udviklingsfora.
+
+Den tekniske komité begrænser sig selv til at vælge blandt, eller vælge et kompromis mellem, løsninger og afgørelser, der er blevet foreslået og er blevet drøftet tilpas meget andre steder.
+
+Medlemmer af den tekniske komité kan selvfølgelig deltage på egne vegne i alle aspekter af udviklings- og retningsliniearbejde.
+
+# Den teknisk komité træffer kun afgørelser som en sidste udvej
+
+Den tekniske komité træffer ikke en teknisk afgørelse før der uden held har været gjort forsøg på at løse problemet ved konsensus, med mindre den er blevet bedt om at træffe en afgørelse af personen eller organet, der normalt ville have haft ansvar for at gøre dette.
+
+1~7 § 7. Projektsekretæren
+
+2~7.1 § 7.1. Fuldmagt
+
+Sekretæren:
+
+# Indsamler stemmer fra udviklerne, finder ud af hvor mange udviklere der er og hvem de er, når dette kræves af vedtægterne.
+
+# Kan vikariere for lederen, i fællesskab med formanden for den tekniske komité.
+
+Hvis der ikke er en projektleder, kan formanden for den tekniske komité og projektsekretæren træffe afgørelser ved enighed, hvis de mener at det er vigtigt at gøre dette.
+
+# Dømmer i stridigheder om tolkning af vedtægterne.
+
+# Kan uddelegere dele af eller hele sin fuldmagt til andre, eller til enhver tid trække en sådan uddelegering tilbage.
+
+2~7.2 § 7.2. Udnævnelse
+
+Projektsekretæren udnævnes af projektlederen og den forrige projektsekretær.
+
+Hvis projektlederen og den forrige projektsekretær ikke kan blive enige om en ny udnævnelse, skal de bede udviklerne om at udnævne en ny sekretær gennem en generel beslutning.
+
+Hvis der ikke er en projektsekretær eller den forrige sekretær ikke kan træffes og ikke har uddelegeret sin fuldmagt til en sådan beslutning, kan beslutningen træffes eller uddelegeres af formanden for den tekniske komité, som fungerende sekretær.
+
+Projektsekretæren er valgt for et år ad gangen, hvorefter en ny (gen)udnævnelse er nødvendig.
+
+2~7.3 § 7.3. Fremgangsmåde
+
+Projektsekretæren bør træffe afgørelser som er retfærdige og rimelige, og helst i overensstemmelse med konsensus blandt udviklerne.
+
+Når projektsekretæren og formanden for den tekniske komité i fællesskab vikarierer for en projektleder som ikke kan træffes, bør de kun træffe beslutninger som er helt nødvendige og kun når det er i overensstemmelse med konsensus blandt udviklerne.
+
+1~8 § 8. Projektlederens delegater
+
+2~8.1 § 8.1. Fuldmagt
+
+Projektlederens delegater:
+
+# har fået uddelegeret en fuldmagt fra projektlederen;
+
+# kan træffe visse afgørelser som lederen ikke kan tage på egen hånd, deriblandt optagelse eller afvisning af udviklere, eller udnævne folk der ikke håndterer pakker, som udviklere. Dette er for at undgå en magtkoncentration hos projektlederen, særligt med hensyn til udviklermedlemskab.
+
+2~8.2 § 8.2. Udnævnelse
+
+Delegaterne udnævnes af projektlederen, og lederen kan udskifte dem, som han finder det passende. Projektlederen kan ikke gøre udnævnelse betinget af at delegaten træffer bestemte afgørelser, lederen kan heller ikke ophævne en beslutning truffet af en delegat.
+
+2~8.3 § 8.3. Fremgangsmåde
+
+Delegater kan til enhver tid træffe afgørelser, men bør prøve at opnå gode tekniske vilkår og/eller følge konsensus.
+
+1~9 § 9. Ejendele der forvaltes på vegne af Debian
+
+I de fleste af verdens jurisdiktioner er Debian-projektet ikke i en situation hvor det direkte må være i besiddelse af midler eller andre ejendele. Derfor er det nødvendigt at ejendele ejes af enhver af en række organisationer, som beskrevet i § 9.2.
+
+Traditionelt var SPI den eneste organisation, der var autoriseret til at forvalte ejendele og beløb for Debian-projektet. SPI blev etableret i USA, for der at forvalte beløb.
+
+SPI og Debian er adskilte organisationer, der har nogle fælles mål. Debian er taknemlig for det juridiske støtteapparat, som SPI tilbyder.
+
+2~9.1 § 9.1. Relationer til tilknyttede organisationer
+
+# Debian-udviklere bliver ikke agenter for eller ansatte af organisationer der forvalter ejendele for Debian, eller af hinanden, eller af persioner med myndighed i Debian-projektet, blot ved at være Debian-udviklere. En person der fungerer som udvikler gør dette som en individuel person, på egne vegne. Sådanne organisationer kan, af egen kraft, etablere relationer mellem individer der også er Debian-udviklere.
+
+2~9.2 § 9.2. Autoritet
+
+# En organisation der forvalter ejendele for Debian har ingen autoritet over Debians tekniske eller ikke-tekniske beslutninger, bortset fra at ingen beslutninger taget af Debian hvad angår ejendele der forvaltes af organisationen må kræve at denne handler uden for sin juridiske autoritet.
+
+# Debian har ingen autoritet over en organisation der forvalter ejendele for Debian, bortset fra over de ejendele der forvaltes for Debian.
+
+2~9.3 Betroede organisationer
+
+Alle donationer til Debian-projektet skal ske til en af de organisationer, som projektlederen (eller en delegat) har autoriseret til at forvalte ejendele til anvendelse af Debian-projektet.
+
+Organisationer der forvalter ejendele for Debian bør påtage sig passende forpligtelser ved forvaltning af sådanne ejendele.
+
+Debian vedligeholder en offentlig liste over betroede organisationer, der accepterer donationer og forvalter ejendele for Debian (deriblandt håndgribelige og intellektuelle ejendele), indeholdende disse organisationers tilsagn til hvordan disse ejendele vil blive forvaltet.
+
+1~a A. Generel resolutionsprocedure
+
+Disse regler gælder fælles beslutninger truffet af komitéer og ved afstemninger, som beskrevet ovenfor.
+
+2~a1 A.1. Forslag
+
+Den formelle procedure begynder når et udkast til en beslutning er foreslået og støttet, som krævet.
+
+2~a1a A.1. Diskussion og ændring
+
+# Efter forslaget er fremsat, kan resolutionen diskuteres. Ændringsforslag kan gøres formelle ved at fremsætte dem og skaffe støtter jævnfør kravene for nye resolutioner, eller direkte af forslagsstilleren af det oprindelige forslag.
+
+# Et formelt ændringsforslag kan accepteres af resolutionens forslagsstiller, hvorved det formelle resolutionsudkast omgående ændres.
+
+# Hvis et formelt ændringsforslag ikke accepteres, eller en af støtterne til resolutionen ikke er enig med forslagsstillerens accept af et formelt ændringsforslag, holdes en særskilt afstemning om dette.
+
+# Hvis andre ikke kan lide et ændringsforslag, som er accepteret af den oprindelige forslagsstiller, kan de foreslå en anden ændring for at fjerne den tidligere ændring (igen skal de leve op til kravene om forslagsstiller og støtte(r).)
+
+# Forslagsstilleren af en resolution kan foreslå revideringer af formuleringen af ændringensforslaget; disse træder i kraft hvis forslagsstilleren af ændringsforslaget er enig og ingen af støtterne protesterer. I så fald stemmes der om det reviderede ændringsforslag i stedet for det oprindelige.
+
+# Forslagsstilleren af en resolution kan foretage ændringer for at rette mindre fejl (for eksempel stavefejl eller selvmodsigelser) eller ændringer som ikke forandrer meningen, såfremt ingen protesterer indenfor 24 timer. I disse tilfælde starter minimumsdiskussionsperioden ikke igen.
+
+2~a2 A.2. Afstemning
+
+# Forslagsstilleren eller en støtte til en resolution eller et ændringsforslag kan bede om afstemning efter at minimumstiden for diskussion (hvis en sådan findes) er gået.
+
+# Foreslagsstilleren eller en støtte til en resolution kan bede om en afstemning vedrørende resolutionen eller alle beslægtede ændringsforslag.
+
+# Personen, der beder om en afstemning, fremsætter hvad vedkommende mener resolutionens og alle relevante ændringsforslags ordlyd skal være, og dermed hvilken udformning afstemningen skal have. Dog er det projektsekretæren som træffer den endelige beslutning - se §§ 7.1(1), 7.1(3), og A.3(4).
+
+# Den minimale diskussionsperiode regnes fra det tidspunkt, det sidste formelle ændringsforslag blev accepteret eller fra det tidspunkt hele resolutionen blev fremsat, hvis ingen ændringer er blevet foreslået og accepteret.
+
+2~a3 A.3. Afstemningsprocedure
+
+# Der stemmes på hver resolution og dennes beslægtede ændringsforslag i en enkelt afstemning, der indeholder en valgmulighed som er den originale resolution, hvert ændringsforslag, samt et standardvalg (hvor det er muligt).
+
+# Standardvalget må ikke have krav om et absolut flertal. Valgmuligheder som ikke eksplicit har krav om absolut flertal, har et 1:1-krav.
+
+# Stemmerne tælles jf. reglerne i A.6. Standardvalget er "Yderligere diskussion" ("Further Discussion"), med mindre andet er angivet.
+
+# I tvivlstilfælde skal projektsekretæren afgøre procedurespørgsmål.
+
+2~a4 A.4. Tilbagetrukne resolutioner og ikke-accepterede ændringsforslag
+
+Foreslagsstilleren af en resolution eller et ændringsforslag som ikke er accepteret, kan trække disse tilbage. I så fald kan andre foreslagsstillere overtage og holde resolutionen eller ændringsforslaget i live, dermed bliver den første person der gør dette, den nye foreslagsstiller og de andre bliver støtter, hvis de ikke allerede er det.
+
+En støtte til en resolution eller en ændring kan trække sig tilbage (med mindre resolutionen allerede er blevet accepteret).
+
+Hvis foreslagsstillers og/eller støttes tilbagetrækning betyder at resolutionen ikke har en foreslagsstiller eller der ikke er støtter nok, holdes der ikke en afstemning, med mindre dette udredes før resolutionen udløber.
+
+2~a5 A.5. Udløb
+
+Hvis en foreslået resolution ikke er blevet diskuteret, ændret, stemt på eller på anden måde taget hånd om i fire uger, kan sekretæren udsende en besked om, at den betragtes som tilbagetrukket. Hvis ingen af foreslagets støtter har indvendiger, trækkes foreslaget tilbage.
+
+Sekretæren kan også vedlægge forslag til hvordan man fortsætter, hvis det er relevat.
+
+2~a6 A.6. Stemmeoptælling
+
+# Hver vælgers stemme prioriterer valgmulighederne. Man behøver ikke at prioritere alle valgmulighederne. Prioriterede valgmuligheder betragtes som foretrukne fremfor valgmuligheder, der ikke er prioriteret. Vælgere kan give valgmuligheder samme prioritet. Valgmuligheder, der ikke er prioriteret, betragtes som ligestillede med hinanden. Nærmere oplysninger om hvordan stemmesedlerne skal udfyldes, vil være vedlagt valgindkaldelsen.
+
+# Hvis det beslutningsdygtige antal er R, vil enhver valgmulighed som ikke er standardvalget og som ikke modtager mindst R stemmer, der prioriterer den mulighed højere end standardvalget, vil ikke blivetaget i betragtning.
+
+# Alle (ikke-standard-) valgmuligheder, der ikke overgår standardvalgmuligheden med dens krævede flertalsgrad, tages ikke i betragtning.
+
+_# Med de to valgmuligheder A og B, er V(A,B) antallet af vælgere der foretrækker mulighed A fremfor mulighed B.
+
+_# Valgmulighed A overgår standardvalgmulighed D med flertalsgraden N, hvis V(A,D) er større end N * V(D,A).
+
+_# Hvis et absolut flertal på S:1 er krævet af A, er dennes flertalsgrad S; ellers er flertalsgraden 1.
+
+# Ud fra listen over valgmuligheder der tages i betragtning, genereres en liste over parvise nederlag.
+
+_# Valgmulighed A overgår mulighed B, hvis V(A,B) er større end V(B,A).
+
+# Ud fra en liste over parvise nederlag (som tages i betragtning), genereres en liste over transitive nederlag.
+
+_# Valgmulighed A overgår transitivt mulighed C, hvis A overgår C eller hvis der er en en mulighed B, hvor A overgår B OG B transitivt overgår C.
+
+# Ud fra sættet af transitive nederlag konstruere et Schwartz-sæt.
+
+_# Valgmulighed A er i Schwartz-sættet hvis, for alle B-muligheders vedkommende, A transitivt overgår B, eller B ikke overgår A transitivt.
+
+# Hvis der er nederlag mellem valgmuligheder i Schwartz-sættet, ses der bort fra de svageste af sådanne nederlag i listen over parvise nederlag, og man springer tilbage til trin 5.
+
+_# Nederlaget (A,X) er svagere end nederlaget (B,Y), hvis V(A,X) er mindre end V(B,Y). Hvis (A,X) desuden er svagere end (B,Y), hvis V(A,X) er lig med V(B,Y) og V(X,A) er større end V(Y,B).
+
+_# Et svageste nederlag, er et nederlag hvortil der ikke er et svagere nederlag. Der kan være mere end et af sådanne nederlag.
+
+# Hvis der ikke nogen nederlag i Schwartz-sættet, tages vinderen fra valgmulighederne i Schwartz-sættet. Hvis der kun er en af disse valgmuligheder, er den vinderen. Hvis der er flere valgmuligheder, afgørerer vælgeren med den afgørende stemme, hvem af disse valgmuligheder, der er vinderen.
+
+Bemærk: Valgmuligheder, som vælgerne prioriterer over standardvalgmuligheden, er muligheder de betragter som acceptable. Valgmuligheder, der prioriteres under standardvalgmuligheder, er muligheder, der betragtes som uacceptable.
+
+Når den generelle resolutionsprocedure anvendes, skal teksten som henviser til denne, fastsætte hvad der er tilstrækkeligt for at få et udkast til en resolution foreslået og/eller støttet, hvad minimumstiden for diskussion er, og hvad afstemningsperioden er. Den skal også fastsætte det eventuelle kvalificerede flertal og beslutningsdygtige antal, som skal anvendes.
+
+1~b B. Brug af sprog og typografi
+
+Nutid ("er", for eksempel) betyder at udtrykket er en regel i disse vedtægter. "Kan" og "skal" indikerer at personen eller organet kan anvende skøn. "Bør" betyder at det vil anses som en god ting om hvis sætningen følges, men den er ikke bindende. Tekst markeret som et citat, som dette, er baggrundsmateriale og udgør ikke en del af vedtægterne. Den kan kun anvendes til at hjælpe med at tolke teksten i tvivlstilfælde.
+
+Bemærk: Dette er en oversættelse af det originale engelsksprogede dokument. Brug altid originalen i diskussioner om vedtægterne, da denne dansksprogede udgave er oversætterens fortolkning, som desuden kan indeholde fejl og misforståelser.
+
+% Deutsch English español français Italiano 日本語 (Nihongo) polski Português Русский (Russkij) svenska
+
+% Sådan opsætter du standardsprogvalg for dokumenter
+
+% For at rapportere et problem med webstedet sendes en e-mail på engelsk til debian-www@lists.debian.org. Se Debians kontaktside for andre kontaktoplysninger.
+
+% Senest opdateret: Tirs 14. nov 2006 kl. 15.41.07 UTC
+% Ophavsretsbeskyttet © 1997-2006 SPI; Se licensbetingelserne
+% Debian er et registreret varemærke tilhørende Software in the Public Interest, Inc.
+
+% Debian-projektet
+
+% Vælg en server i nærheden af dig
+
+% Spring navigering over
+
+% * Om Debian
+% * Nyheder
+% * Få fat i Debian
+% * Support
+% * Udviklerhjørnet
+% * Sideoversigt
+% * Søg
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.3~de.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.3~de.sst
new file mode 100644
index 00000000..4ff0812c
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_constitution_v1.3~de.sst
@@ -0,0 +1,503 @@
+% SiSU 2.0
+
+% Zuletzt geändert: Mittwoch den 15. Nov 2006 um 22:29:40 Uhr UTC
+% Copyright © 1997-2006 SPI; Hier die Lizenzbestimmungen
+% Debian ist ein eingetragenes Warenzeichen von Software in the Public Interest, Inc.
+
+@title: Debian-Verfassung
+ :subtitle: Verfassung für das Debian-Projekt
+ :edition: v1.3
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution;language:German
+
+@date:
+ :published: 2003-10-29
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2006-09-24
+ :available: 2006-09-24
+ :modified: 2006-11-15
+
+@language:
+ :document: German
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.de.html <br> "Debian" und das Debian-Logo http://www.debian.org/logos/ sind Warenzeichen von Software in the Public Interest, Inc.
+ :license: Dieses Material darf nur unter den Bestimmungen, die in der Open Publication License, Draft v1.0 oder später (Sie können unsere lokale Kopie lesen http://www.debian.org/opl, die neuste Version ist normalerweise unter unter http://www.opencontent.org/openpub/ verfügbar) festgehalten sind, weitergegeben werden.
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Dies ist die am 24. September 2006 ratifizierte Version 1.3. Sie ersetzt die am 29. Oktober 2003 ratifizierte Version 1.2 und die am 21. Juni 2003 ratifizierte Version 1.1, welche ihrerseits die am 2. Dezember 1998 ratifizierte Version 1.0 ersetzt.<br> Dies ist die deutsche Übersetzung von "Debian's license" http://www.debian.org/license.en.html. In Zweifelsfällen ist das englische Original maßgeblich.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.3.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Debian-Verfassung
+
+:B~ Verfassung für das Debian-Projekt (v1.3)
+
+1~pre [Prefix]-#
+
+Dies ist die am 24. September 2006 ratifizierte { Version 1.3 }http://www.debian.org/devel/constitution.1.3. Sie ersetzt die am 29. Oktober 2003 ratifizierte { Version 1.2 }http://www.debian.org/devel/constitution.1.2 und die am 21. Juni 2003 ratifizierte { Version 1.1 }http://www.debian.org/devel/constitution.1.1, welche ihrerseits die am 2. Dezember 1998 ratifizierte { Version 1.0 }http://www.debian.org/devel/constitution.1.0 ersetzt.
+
+1~ Einleitung
+
+/{Das Debian-Projekt ist ein Verband von Einzelpersonen, die die Schaffung eines freien Betriebssystems zu ihrem gemeinsamen Anliegen gemacht haben.}/
+
+Dieses Dokument beschreibt die Organisationsstruktur für formelle Entscheidungsfindung innerhalb des Projekts. Es beschreibt nicht die Ziele des Projekts oder wie es diese erreicht, und es enthält keine Richtlinien außer denen, die sich direkt auf den Prozess der Entscheidungsfindung beziehen.
+
+2~ Entscheidungsfindende Organe und Einzelpersonen
+
+Jede Entscheidung innerhalb des Projekts wird von einem oder mehreren der folgenden Organe und Einzelpersonen getroffen:
+
+# Den Entwicklern, durch einen Allgemeinen Beschluss oder eine Wahl.
+
+# Dem Projektleiter;
+
+# Dem Technischen Ausschuss und/oder seinem Vorsitzenden;
+
+# Dem an einer einzelnen Aufgabe arbeitenden Entwickler;
+
+# Vom Projektleiter für bestimmte Aufgaben ernannten Delegierten;
+
+# Dem Projekt-Schriftführer.
+
+Das meiste vom Rest dieses Dokuments beschreibt die Befugnisse dieser Organe, ihre Zusammensetzung und Ernennung und das Verfahren bei ihrer Entscheidungsfindung. Die Befugnisse einer Person oder eines Organs können der Überwachung und/oder Einschränkung durch Andere unterworfen sein; in diesem Fall gibt dies der Eintrag des überwachenden Organs oder der Person an. In der obigen Liste ist eine Person oder ein Organ in der Regel vor irgendwelchen Personen oder Organen aufgeführt, deren Entscheidungen sie aufheben können oder die sie ernennen (oder ihnen dabei helfen) – jedoch kann nicht jeder, der vorher aufgeführt wird, jeden, der nachher aufgeführt wird, überstimmen.
+
+2~ Allgemeine Vorschriften
+
+# Nichts in dieser Verfassung erlegt irgendjemandem die Verpflichtung auf, für das Projekt Arbeit zu verrichten. Eine Person, die eine an sie delegierte oder ihr zugewiesene Aufgabe nicht erledigen möchte, muss es nicht tun. Jedoch darf sie nicht diesen Vorschriften oder Entscheidungen, die nach diesen Vorschriften ordnungsgemäß getroffen wurden, aktiv entgegenwirken.
+
+# Eine Person kann verschiedene Ämter innehaben, mit der Ausnahme, dass sich der Projektleiter, der Projekt-Schriftführer und der Vorsitzende des Technischen Ausschusses unterscheiden müssen, und dass der Projektleiter sich nicht zu seinem eigenen Delegierten ernennen kann.
+
+# Eine Person kann das Projekt verlassen oder ein bestimmtes Amt zu jeder Zeit niederlegen, indem sie dies öffentlich erklärt.
+
+1~ Einzelne Entwickler
+
+2~ Befugnisse
+
+Ein einzelner Entwickler darf
+
+# jede technische oder nicht-technische Entscheidung hinsichtlich seiner eigenen Arbeit treffen;
+
+# einen Entwurf zu einem Allgemeinen Beschluss einbringen oder befürworten;
+
+# sich bei Wahlen selbst als Kandidat für das Amt des Projektleiters vorschlagen;
+
+# bei Allgemeinen Beschlüssen und bei Wahlen über die Leitung abstimmen.
+
+2~ Zusammensetzung und Ernennung
+
+# Entwickler sind Freiwillige, die sich darin einig sind, die Ziele des Projekts insofern zu fördern, als sie an ihm teilhaben, und die ein oder mehrere Pakete für das Projekt betreuen oder andere Arbeit verrichten, welche der oder die Delegierten des Projektleiters als lohnenswert erachten.
+
+# Der oder die Delegierten des Projektleiters können es vorziehen, keine neuen Entwickler aufzunehmen, oder vorhandene Entwickler auszuschließen. Wenn die Entwickler verspüren, dass die Delegierten ihre Autorität missbrauchen, können sie selbstverständlich die Entscheidung durch einen Allgemeinen Beschluss außer Kraft setzen - siehe §4.1(3), §4.2.
+
+2~ Verfahren
+
+Entwickler können diese Entscheidungen treffen, wie sie es für richtig halten.
+
+1~ Die Entwickler durch einen Allgemeinen Beschluss oder Wahl
+
+2~ Befugnisse
+
+Zusammen können die Entwickler
+
+# Den Projektleiter ernennen oder abberufen.
+
+# Diese Verfassung abändern, vorausgesetzt, sie stimmen dem mit einer 3:1-Mehrheit zu.
+
+# Jede Entscheidung treffen oder außer Kraft setzen, zu der der Projektleiter oder einer seiner Delegierten befugt ist.
+
+# Jede Entscheidung treffen oder außer Kraft setzen, zu der der Technische Ausschuss befugt ist, vorausgesetzt sie stimmen diesem mit einer 2:1-Mehrheit zu.
+
+# Nicht-technische schriftliche Richtlinien und Erklärungen herausgeben, ersetzen und zurückziehen.
+
+Diese beinhalten Dokumente, welche die Ziele des Projekts und seine Beziehung zu anderen Gebilden der Freien Software beschreiben, sowie nicht-technische Richtlinien wie die Lizenzbedingungen für Freie Software, die Debian-Software erfüllen muss.
+
+Sie können auch Positionserklärungen zu Tagesfragen hinzufügen.
+
+_# Ein Gründungsdokument ist ein Dokument oder eine Erklärung, die als entscheidend für den Auftrag und die Zwecke des Projekts betrachtet werden.
+
+_# Die Gründungsdokumente sind die Arbeiten mit dem Titel Debian-Gesellschaftsvertrag und Debian Richtlinien für freie Software.
+
+_# Ein Gründungsdokument benötigt eine 3:1-Mehrheit, um ersetzt zu werden. Durch Abändern der Liste der Gründungsdokumente in dieser Verfassung werden neue Gründungsdokumente herausgegeben und vorhandene zurückgezogen.
+
+# Entscheidungen über treuhänderisch verwaltetes Eigentum treffen, welches mit den Zwecken von Debian in Beziehung steht. (Siehe §9.)
+
+# Im Falle einer Meinungsverschiedenheit zwischen dem Projektleiter und dem amtierenden Schriftführer einen neuen Schriftführer ernennen.
+
+2~ Verfahren
+
+# Die Entwickler befolgen das Standard-Beschlussverfahren – siehe weiter unten. Einen Beschluss oder Abänderung wird eingebracht, indem sie von irgendeinem Entwickler beantragt und von mindestens K anderen Entwicklern befürwortet wird, oder wenn sie vom Projektleiter oder Technischen Ausschuss beantragt wird.
+
+# Aufschieben einer Entscheidung des Projektleiters oder seines Delegierten:
+
+_# Wenn der Projektleiter, sein Delegierter oder der Technische Ausschuss eine Entscheidung getroffen hat, können Entwickler diese überstimmen, indem sie dazu einen Beschluss verabschieden; siehe §4.1(3).
+
+_# Wenn ein solcher Beschluss von wenigstens 2K Entwicklern befürwortet oder vom Technischen Ausschuss beantragt wird, vertagt der Beschluss die Entscheidung unmittelbar (vorausgesetzt, dieser Beschluss selbst besagt dies).
+
+_# Falls die ursprüngliche Entscheidung darin bestand, eine Diskussions- oder Abstimmungsfrist zu ändern, oder wenn der Beschluss darin besteht, den Technischen Ausschuss zu überstimmen, dann brauchen nur K Entwickler den Beschluss zu befürworten, um die Entscheidung unmittelbar vertagen zu können.
+
+_# Falls die Entscheidung vertagt wird, wird eine sofortige Abstimmung abgehalten, um zu bestimmen, ob die Entscheidung solange bestehen bleibt, bis die vollständige Abstimmung über die Entscheidung durchgeführt wurde, oder ob die Erfüllung der ursprünglichen Entscheidung bis dahin verzögert wird. Es gibt bei dieser unmittelbaren verfahrensbezogenen Abstimmung kein Quorum.
+
+_# Falls der Projektleiter (oder der Delegierte) die ursprüngliche Entscheidung zurückzieht, so wird die Abstimmung gegenstandslos und wird nicht weiter durchgeführt.
+
+# Der Projekt-Schriftführer lässt abstimmen. Stimmen, Stimmensummen und Ergebnisse werden während der Abstimmungsfrist nicht offen gelegt; nach der Abstimmung listet der Projekt-Schriftführer alle abgegebenen Stimmen auf. Die Abstimmungsfrist beträgt zwei Wochen, kann aber durch den Projektleiter um bis zu eine Woche variiert werden.
+
+# Die Mindestfrist für Diskussionen beträgt zwei Wochen, kann aber durch den Projektleiter um bis zu eine Woche variiert werden. Die Stimme des Projektleiters gibt den Ausschlag. Es gibt ein Quorum von 3Q.
+
+# Anträge, Befürwortungen, Abänderungen, Aufrufe zur Abstimmung und andere formelle Handlungen werden auf einer für die Öffentlichkeit lesbaren Mailingliste bekanntgegeben, die von dem bzw. den Delegierten des Projekt-Leiters bestimmt wird; jeder Entwickler kann dort Beiträge abgeben.
+
+# Stimmen werden in einer für den Schriftführer geeigneten Weise durch E-Mail abgegeben. Der Schriftführer legt für jede Abstimmung fest, ob die Abstimmenden ihre Stimme ändern können.
+
+# Q ist die Hälfte der Quadratwurzel aus der Anzahl der gegenwärtigen Entwickler. K ist Q oder 5, je nachdem, welches davon kleiner ist. Q und K brauchen nicht ganze Zahlen sein und werden nicht gerundet.
+
+1~ Projektleiter
+
+2~ Befugnisse
+
+Der Projektleiter darf
+
+# Delegierte ernennen oder Entscheidungen an den Technischen Ausschuss delegieren.
+
+Der Leiter darf einen Bereich mit fortlaufender Verantwortung oder eine bestimmte Entscheidung festlegen und diese an einen anderen Entwickler oder den Technischen Ausschuss übergeben.
+
+Sobald eine bestimmte Entscheidung delegiert und getroffen wurde, darf der Projektleiter diese Delegierung nicht zurückziehen; jedoch darf er eine fortlaufende Delegierung eines bestimmten Verantwortungsbereichs zurückziehen.
+
+# Anderen Entwicklern Vollmacht erteilen.
+
+Der Projektleiter kann Erklärungen zur Unterstützung von Standpunkten oder von anderen Mitgliedern des Projekts abgeben, gebeten oder ungebeten; diese Erklärungen haben dann und nur dann Kraft, wenn der Projektleiter befugt wäre, die fragliche Entscheidung zu treffen.
+
+# Jede Entscheidung treffen, welche dringende Handlung erfordert.
+
+Dies gilt nicht für Entscheidungen, die nur durch einen Mangel an entsprechenden Maßnahmen allmählich dringend geworden sind, außer wenn es einen festen Stichtag gibt.
+
+Jede Entscheidung treffen, für die niemand sonst Verantwortung trägt.
+
+# Entwürfe für Allgemeine Beschlüsse und Abänderungen einbringen.
+
+# Zusammen mit dem Technischen Ausschuss neue Mitglieder in den Ausschuss berufen. (Siehe §6.2.)
+
+# Sich einer ausschlaggebenden Stimme bedienen, wenn Entwickler abstimmen.
+
+Der Projektleiter hat auch eine normale Stimme bei solchen Abstimmungen.
+
+# Die Diskussionsfrist für Abstimmungen der Entwickler variieren (wie oben).
+
+# Diskussionen unter Entwicklern leiten.
+
+Der Projektleiter sollte versuchen, an Diskussionen unter den Entwicklern auf eine hilfreiche Weise teilzunehmen, die versucht, die Diskussion zu den vorhandenen Kernproblemen zu bringen. Der Projektleiter sollte nicht seine Leitungsposition benutzen, um seine eigenen persönlichen Ansichten zu befördern.
+
+# Im Einvernehmen mit den Entwicklern Entscheidungen fällen, die treuhänderisch verwaltetes Eigentum betreffen, welches mit den Zwecken von Debian in Beziehung steht. (Siehe §9.) Solche Entscheidungen werden den Mitgliedern durch den Projektleiter oder dessen Delegierte(n) mitgeteilt. Bedeutendere Ausgaben sollten beantragt und auf den Mailinglisten debattiert werden, bevor Gelder ausgezahlt werden.
+
+# Der Liste von vertrauenswürdigen Organisationen (siehe §9.3) Organisationen hinzufügen oder entfernen, die befugt sind, für Debian Vermögen anzunehmen und zu verwalten. Die zu einer solchen Entscheidung führende Beurteilung und Diskussion findet auf einer vom Projektleiter oder seines/seiner Delegierten bestimmten Mailingliste statt, auf der jeder Entwickler Beiträge abgeben kann. Es besteht eine Diskussionsfrist von mindestens zwei Wochen, bevor eine Organisation der Liste vertrauenswürdiger Organisationen hinzugefügt werden kann.
+
+2~ Ernennung
+
+# Der Projektleiter wird von den Entwicklern gewählt.
+
+# Die Wahl beginnt neun Wochen, bevor das Amt der Leitung frei wird, oder (wenn es bereits zu spät ist) sofort.
+
+# In den darauf folgenden drei Wochen kann jeder Entwickler sich selbst als Kandidat für das Amt des Projektleiters nominieren.
+
+# Danach können für drei Wochen keine weiteren Kandidaten nominiert werden; Kandidaten sollten diese Zeit für die Wahlkampagne nutzen (um ihre Person und Positionen bekannt zu machen). Falls es am Ende der Nominierungsfrist keine Kandidaten gibt, so wird die Nominierung um weitere drei Wochen verlängert – falls nötig, wiederholt.
+
+# Die nächsten drei Wochen sind der Abstimmungszeitraum, in der Entwickler ihre Stimmen abgeben können. Stimmen bei Wahlen für das Amt des Projektleiters werden geheimgehalten, sogar nachdem die Abstimmung beendet ist.
+
+# Die Wahlmöglichkeiten auf dem Stimmzettel sind diejenigen Kandidaten, die sich selbst nominiert und die Kandidatur noch nicht zurückgezogen haben, und zusätzlich Niemand von den Obigen. Falls Niemand von den Obigen die Wahl gewinnt, so wird das Wahlverfahren wiederholt – viele Male, falls nötig.
+
+# Die Entscheidung wird nach der in §A.6 des Standard-Beschlussverfahrens bestimmten Methode getroffen. Das Quorum ist dasselbe wie für einen Allgemeinen Beschluss (§4.2), und die Vorgabe-Wahlmöglichkeit ist Niemand von den Obigen.
+
+# Der Projektleiter amtiert nach seiner Wahl ein Jahr lang.
+
+2~ Verfahren
+
+Der Projektleiter sollte versuchen, Entscheidungen zu treffen, die mit dem Meinungskonsens der Entwickler vereinbar sind.
+
+Sofern es praktikabel ist, sollte der Projektleiter sich informell um die Ansichten der Entwickler bemühen.
+
+Der Projektleiter sollte es vermeiden, seinen eigenen Standpunkt übermäßig zu betonen, wenn er in seiner Eigenschaft als Projektleiter Entscheidungen trifft.
+
+1~ Technischer Ausschuss
+
+2~ Befugnisse
+
+Der Technische Ausschuss darf
+
+# Über jede Angelegenheit entscheiden, die technische Grundsätze betrifft.
+
+Dies schließt die Inhalte der Handbücher für technische Richtlinien, Nachschlagematerial für Entwickler, Beispielpakete und das Verhalten nicht-experimenteller Paketbau-Werkzeuge ein. (In jedem dieser Fälle trifft jedoch der übliche Betreuer der entsprechenden Software oder Dokumentation anfänglich Entscheidungen; siehe §6.3.(5).)
+
+# Über jede technische Angelegenheit entscheiden, in der sich die Entscheidungsbefugnisse von Entwicklern überlappen.
+
+In Fällen, bei denen Entwickler technische Richtlinien oder Standpunkte erfüllen müssen, die miteinander vereinbar sind (zum Beispiel, wenn sie über die Priorität miteinander im Konflikt stehender Pakete oder über das Eigentum am Namen eines Befehls verschiedener Meinung sind; oder darüber, welches Paket für einen Fehler verantwortlich ist, bei dem beide Betreuer sich einig sind, dass er ein Fehler ist; oder darüber, wer der Betreuer eines Pakets sein sollte), kann der technische Ausschuss die Angelegenheit entscheiden.
+
+# Eine Entscheidung treffen, wenn er darum gebeten wird.
+
+Jede Person und jedes Organ kann eine eigene Entscheidung an den Technischen Ausschuss delegieren, oder von ihm Rat einholen.
+
+# Einen Entwickler überstimmen (benötigt eine 3:1-Mehrheit).
+
+Der Technische Ausschuss kann einen Entwickler darum bitten, einen bestimmten technischen Handlungsweg zu beschreiten, sogar wenn der Entwickler dies nicht wünscht; dazu wird eine 3:1-Mehrheit benötigt. Zum Beispiel kann der Ausschuss festlegen, dass eine Beanstandung, die vom Einsender eines Fehlerberichts erhoben wurde, gerechtfertigt ist, und dass die vom Einsender vorgeschlagene Lösung erfüllt werden sollte.
+
+# Rat anbieten.
+
+Der Technische Ausschuss kann seine Ansichten über jegliche Angelegenheit formell bekannt machen. Einzelne Mitglieder können natürlich informelle Erklärungen über ihre Ansichten und über die voraussichtlichen Ansichten des Ausschusses abgeben.
+
+# Zusammen mit dem Projektleiter neue Mitglieder in den Ausschuss berufen oder vorhandene Mitglieder abberufen. (Siehe §6.2.)
+
+# Den Vorsitzenden des Technischen Ausschusses ernennen.
+
+Der Vorsitzende wird vom Ausschuss aus seinen Mitgliedern gewählt. Alle Mitglieder des Ausschusses werden automatisch nominiert; der Ausschuss beginnt eine Woche vor dem Freiwerden des Amtes zu wählen (oder sofort, wenn es bereits zu spät ist). Die Mitglieder können durch öffentliche Akklamation (d.h. Zuruf) für jedes Mitglied des Ausschusses stimmen, inklusive ihrer selbst; es gibt keine Vorgabe-Wahlmöglichkeit. Die Abstimmung endet, wenn alle Mitglieder abgestimmt haben, oder wenn die Abstimmungsfrist abgelaufen ist. Das Ergebnis wird durch die in §A.6 des Standard-Beschlussverfahrens bestimmte Methode festgelegt.
+
+# Der Vorsitzende kann den Projektleiter zusammen mit dem Schriftführer vertreten.
+
+Wie in §7.1(2) detailliert beschrieben wird, können der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer zusammen den Projektleiter vertreten, falls es keinen Projektleiter gibt.
+
+2~ Zusammensetzung
+
+# Der Technische Ausschuss besteht aus bis zu 8 Entwicklern und sollte für gewöhnlich mindestens 4 Mitglieder haben.
+
+# Wenn es weniger als 8 Mitglieder gibt, kann der Technische Ausschuss dem Projektleiter ein oder mehrere neue Mitglieder empfehlen, der seinerseits (im Einzelfall) entscheiden kann, ob er sie ernennt oder nicht.
+
+# Wenn es 5 oder weniger Mitglieder gibt, kann der Technische Ausschuss ein oder mehrere Mitglieder ernennen, bis die Anzahl der Mitglieder 6 erreicht.
+
+# Wenn es für mindestens eine Woche 5 oder weniger Mitglieder gegeben hat, kann der Projektleiter ein oder mehrere neue Mitglieder ernennen, bis die Anzahl der Mitglieder 6 erreicht – dies in Abständen von mindestens einer Woche pro Ernennung.
+
+# Falls der Technische Ausschuss und der Projektleiter sich einig sind, können sie ein im Technischen Ausschuss vorhandenes Mitglied entfernen oder ersetzen.
+
+2~ Verfahren
+
+# Der Technische Ausschuss bedient sich des Standard-Beschlussverfahrens.
+
+Ein Beschlussentwurf oder eine Abänderung kann von jedem Mitglied des Technischen Ausschusses vorgeschlagen werden. Es gibt keine Mindestfrist für Diskussionen; die Abstimmungsfrist dauert bis zu einer Woche, oder bis über den Ausgang kein Zweifel mehr besteht. Mitglieder können ihre Stimmen ändern. Das Quorum beträgt 2.
+
+# Einzelheiten, die die Abstimmung betreffen.
+
+Der Vorsitzende hat eine ausschlaggebende Stimme. Wenn der Technische Ausschuss darüber abstimmt, ob ein Entwickler, der ebenfalls Mitglied des Ausschusses ist, überstimmt werden soll, so darf dieser Entwickler nicht abstimmen (es sei denn, er ist der Vorsitzende – in diesem Fall kann er nur seine ausschlaggebende Stimme benutzen).
+
+# Öffentliche Diskussion und Entscheidungsfindung.
+
+Diskussion, Beschlussentwürfe und Abänderungen, sowie Stimmen von Mitgliedern des Ausschusses werden auf der öffentlichen Diskussionsliste des Technischen Ausschusses veröffentlicht. Es gibt keinen gesonderten Schriftführer für den Ausschuss.
+
+# Vertraulichkeit der Ernennungen.
+
+Der Technische Ausschuss kann vertrauliche Diskussionen durch private E-Mail, eine private Mailingliste oder andere Mittel abhalten, um Ernennungen in den Ausschuss zu diskutieren. Jedoch müssen Abstimmungen über Ernennungen öffentlich sein.
+
+# Keine Entwurfsarbeit in Einzelheiten.
+
+Der Technische Ausschuss nimmt nicht am Entwurf neuer Vorschläge oder Richtlinien teil. Solche Entwurfsarbeit sollte von Einzelpersonen für sich oder zusammen durchgeführt werden und in gewöhnlichen Foren für technische Richtlinien und Entwürfe diskutiert werden.
+
+Der Technische Ausschuss beschränkt sich darauf, Kompromisse zwischen Lösungen und Entscheidungen, welche anderswo vorgeschlagen und hinreichend gründlich diskutiert worden sind, auszuwählen oder aufzunehmen.
+
+Einzelne Mitglieder des Technischen Ausschusses können selbstverständlich in eigener Sache an jedem Aspekt der Arbeit an Entwürfen und Richtlinien teilhaben.
+
+# Der Technische Ausschuss fasst Beschlüsse nur als letzten Ausweg.
+
+Der Technische Ausschuss trifft keine technische Entscheidung, solange nicht Anstrengungen, diese durch einen Konsens zu entscheiden, unternommen wurden und fehlgeschlagen sind, außer wenn er von der Person oder dem Organ, das normalerweise dafür verantwortlich ist, darum gebeten wurde, eine Entscheidung zu treffen.
+
+1~ Der Projekt-Schriftführer
+
+2~ Befugnisse
+
+Der Schriftführer
+
+# Lässt unter den Entwicklern abstimmen und bestimmt die Anzahl und Person der Entwickler, wann immer dies die Verfassung erfordert.
+
+# Kann zusammen mit dem Vorsitzenden des Technischen Ausschusses an die Stelle des Projektleiters treten.
+
+Wenn es keinen Projektleiter gibt, können der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer in gegenseitigem Einvernehmen Entscheidungen treffen, wenn sie dies als unumgänglich betrachten.
+
+# Über jegliche Streitigkeit urteilen, die die Auslegung der Verfassung betrifft.
+
+# Kann seine Befugnisse teilweise oder vollständig an jemand anderen übertragen oder eine solche Delegierung zu jeder Zeit zurücknehmen.
+
+2~ Ernennung
+
+Der Projekt-Schriftführer wird vom Projektleiter und dem gegenwärtigen Projekt-Schriftführer ernannt.
+
+Wenn der Projektleiter und der gegenwärtige Projekt-Schriftführer sich nicht auf eine neue Ernennung einigen können, müssen sie die Entwickler auf dem Weg eines Allgemeinen Beschlusses darum bitten, einen Schriftführer zu ernennen.
+
+Wenn es keinen Projekt-Schriftführer gibt, oder der gegenwärtige Projekt-Schriftführer nicht erreichbar ist und seine Vollmacht über eine Entscheidung nicht abgegeben hat, kann der Vorsitzende des Technischen Ausschusses als stellvertretender Schriftführer die Entscheidung treffen oder delegieren.
+
+Die Amtszeit des Projekt-Schriftführers beträgt 1 Jahr, nach dessen Ablauf dieser oder ein anderer Schriftführer (wieder-)ernannt werden muss.
+
+2~ Verfahren
+
+Der Projekt-Schriftführer sollte gerechte und vernünftige Entscheidungen treffen, die vorzugsweise mit dem Konsens der Entwickler vereinbar sind.
+
+Wenn der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer zusammen stellvertretend für einen abwesenden Projektleiter handeln, sollten sie nur wenn absolut notwendig Entscheidungen treffen, und nur, wenn diese vereinbar mit dem Konsens der Entwickler sind.
+
+1~ Die Delegierten des Projektleiters
+
+2~ Befugnisse
+
+Die Delegierten des Projektleiters
+
+# haben vom Projektleiter an sie delegierte Befugnisse;
+
+# dürfen gewisse Entscheidungen treffen, die der Leiter nicht auf direkte Weise treffen darf. Dazu gehört, Entwickler anzuerkennen oder zu verweisen, oder Personen zu Entwicklern zu bestimmen, die keine Pakete betreuen. Dies dient dazu, eine Konzentration von Macht, besonders eine über Mitgliedschaft von Entwicklern, in den Händen des Projektleiters zu verhindern.
+
+2~ Ernennung
+
+Die Delegierten werden durch den Projektleiter ernannt und können vom Projektleiter nach seinem Ermessen ersetzt werden. Der Projektleiter kann weder die Position des Delegierten von bestimmten Entscheidungen des Delegierten abhängig machen, noch kann er sich über eine Entscheidung hinwegsetzen, die einmal von einem Delegierten getroffen wurde.
+
+2~ Verfahren
+
+Delegierte können Entscheidungen treffen, wie sie es für richtig halten, jedoch sollten sie versuchen, gute technische Entscheidungen zu vollziehen und/oder dem Meinungskonsens zu folgen.
+
+1~ Für Debian treuhänderisch verwaltetes Vermögen
+
+In den meisten Gerichtsbarkeiten auf der Welt ist Debian nicht in der Lage, direkt Vermögen oder anderes Eigentum zu besitzen. Daher muss Eigentum von einer Reihe von Organisationen besessen werden, wie in §9.2 genauer beschrieben wird.
+
+Traditionell war SPI die einzige Organisation, die befugt war, Eigentum und Gelder für das Debian-Projekt zu besitzen. SPI wurde in den Vereinigten Staaten gegründet, um dort Geld treuhänderisch zu verwalten.
+
+SPI und Debian sind getrennte Organisationen, welche einige Ziele miteinander teilen. Debian ist dankbar für die rechtliche Unterstützung, die SPI anbietet.
+
+2~ Beziehung zu angegliederten Organisationen
+
+# Debian-Entwickler werden nicht allein durch den Vorzug, Debian-Entwickler zu sein, Beauftragte oder Angestellte von für Debian treuhänderisch Vermögen verwaltenden Organisationen, oder voneinander, oder von Personen mit Befugnis im Debian-Projekt. Eine als Entwickler handelnde Person tut dies als Einzelperson, im eigenen Namen. Solche Organisationen dürfen jedoch aus eigenem Antrieb Beziehungen zu Einzelpersonen unterhalten, die auch Debian-Entwickler sind.
+
+2~ Befugnisse
+
+# Eine Organisation, welche für Debian Vermögen verwaltet, hat keine Befugnis hinsichtlich Debians technischer oder nichttechnischer Entscheidungen, außer, dass keine von Debians Entscheidungen bezüglich irgendwelchen von der Organisation verwalteten Eigentums von der Organisation verlangen möge, außerhalb ihrer rechtlichen Befugnis zu handeln.
+
+# Debian beansprucht keine Befugnis über eine Organisation, welche Vermögen für Debian verwaltet, außer der Benutzung des für Debian treuhänderisch verwalteten Eigentums.
+
+2~ 9.3. Vertrauenswürdige Organisationen
+
+Jegliche Spenden für das Debian-Projekt müssen an eine aus einer Reihe von Organisationen gehen, die vom Projektleiter (oder eines Delegierten) dazu ernannt wurden, für den Umgang mit für das Debian-Projekt verwendetem Vermögen befugt zu sein.
+
+Organisationen, die für Debian Vermögen treuhänderisch verwalten, sollten für den Umgang mit diesem Vermögen angemessene Verpflichtungen eingehen.
+
+Debian unterhält eine öffentliche Liste von vertrauenswürdigen Organisationen (List of Trusted Organisations), die Spenden annehmen und für Debian Vermögen treuhänderisch verwalten (hierbei sind sowohl Sachvermögen als auch geistiges Eigentum inbegriffen). Die Liste enthält sowohl die Verpflichtungen, die diese Organisationen eingehen, als auch wie mit diesem Vermögen umgegangen wird.
+
+1~a A. Standard-Beschlussverfahren
+
+Diese Vorschriften betreffen gemeinschaftliche Entscheidungsfindung durch Ausschüsse sowie direkte Abstimmungen, wie oben angegeben.
+
+2~a1 A.1. Beantragung
+
+Das formelle Verfahren beginnt, wenn ein Beschlussentwurf beantragt und befürwortet wird, je nach Bedarf.
+
+2~a1a A.1. Diskussion und Abänderung
+
+# Nach der Beantragung kann der Beschluss diskutiert werden. Abänderungen können formell gemacht werden, indem sie entsprechend den Anforderungen an einen neuen Beschluss beantragt und befürwortet werden, oder auf direktem Wege durch den Antragsteller des ursprünglichen Beschlusses.
+
+# Eine formelle Abänderung kann durch den Antragsteller des Beschlusses angenommen werden. In diesem Fall wird der formelle Beschlussentwurf unmittelbar mit der Abänderung in Übereinstimmung gebracht.
+
+# Wenn eine formelle Abänderung nicht angenommen wird, oder einer der Befürworter des Beschlusses nicht mit der Annahme durch den Antragsteller einer formellen Abänderung einverstanden ist, bleibt die Abänderung eine Abänderung und es wird über sie abgestimmt.
+
+# Wenn eine vom ursprünglichen Antragsteller angenommene Abänderung nicht nach dem Geschmack Anderer ist, können diese eine weitere Abänderung einbringen, um die frühere Veränderung umzukehren (wieder müssen sie dann Antragsteller und Befürworter gemäß der Anforderungen sein).
+
+# Der Antragsteller eines Beschlusses kann Veränderungen an der Formulierung von Abänderungen vorschlagen; diese werden wirksam, wenn der Antragsteller der Abänderung damit einverstanden ist und keiner der Befürworter dagegen ist. In diesem Fall wird anstelle der ursprünglichen über die veränderten Abänderungen abgestimmt.
+
+# Der Antragsteller eines Beschlusses kann Veränderungen vornehmen, um unbedeutende Fehler (zum Beispiel Schreibfehler oder Ungereimtheiten) zu berichtigen, oder Veränderungen vornehmen, die nicht den Sinn ändern, vorausgesetzt niemand erhebt innerhalb von 24 Stunden Einwände. In diesem Fall beginnt die Mindestfrist für Diskussionen nicht von vorn.
+
+2~a2 A.2. Aufruf zur Abstimmung
+
+# Der Antragsteller oder ein Befürworter eines Antrages oder einer Abänderung kann zur Abstimmung aufrufen, vorausgesetzt, dass die Mindestfrist für Diskussionen (falls vorhanden) abgelaufen ist.
+
+# Der Antragsteller und jeder Befürworter eines Beschlusses können zu einer Abstimmung über diesen Beschluss und alle damit zusammenhängenden Abänderungen aufrufen.
+
+# Die Person, welche zu einer Abstimmung aufruft, gibt bekannt, welches ihrer Ansicht nach die Formulierung des Beschlusses und relevanter Abänderungen sind, und folglich, welche Form der Stimmzettel annehmen sollte. Dennoch liegt die endgültige Entscheidung über die Form des/der Stimmzettel beim Schriftführer – siehe §§7.1(1), 7.1(3) und A.3(4).
+
+# Die Mindestfrist für Diskussionen zählt ab dem Zeitpunkt, zu dem die letzte formelle Abänderung angenommen wurde, oder ab dem Zeitpunkt, zu dem der ganze Beschluss vorgeschlagen wurde, falls keine Abänderungen vorgeschlagen und angenommen wurden.
+
+2~a3 A.3. Wahlverfahren
+
+# Über jeden Beschluss und die damit zusammenhängenden Abänderungen wird auf einem einzigen Wahlzettel abgestimmt, der jeweils eine Wahlmöglichkeit für den ursprünglichen Beschluss, jede Abänderung und die Vorgabe-Wahlmöglichkeit (wo anwendbar) enthält.
+
+# Die Vorgabe-Wahlmöglichkeit darf keine Supermajorität erfordern. Wahlmöglichkeiten, die nicht explizit eine Supermajorität erfordern, erfordern eine 1:1-Mehrheit.
+
+# Die Stimmen werden nach den Vorschriften in §A.6. gezählt. Die Vorgabe-Wahlmöglichkeit heißt Weitere Diskussion, wenn nicht eine andere bestimmt wurde.
+
+# In Zweifelsfällen entscheidet der Projekt-Schriftführer über Angelegenheiten des Verfahrens.
+
+2~a4 A.4. Zurückziehen von Beschlüssen oder nicht angenommenen Abänderungen
+
+Der Antragsteller eines Beschlusses oder einer nicht angenommenen Abänderung kann diese zurückziehen. In diesem Fall können neue Antragsteller hervortreten, um sie am Leben zu halten; dann wiederum wird die erste Person, die dies tut, der neue Antragsteller, und alle anderen werden Befürworter, wenn sie dies nicht bereits sind.
+
+Ein Befürworter eines Beschlusses oder einer Abänderung (es sei denn, sie wurde angenommen) kann seine Befürwortung zurückziehen.
+
+Wenn die Zurückziehung durch den Antragsteller und/oder die Befürworter bedeutet, dass der Beschluss keinen Antragsteller oder nicht genug Befürworter hat, wird über sie nicht abgestimmt, es sei denn, dies wird berichtigt, bevor der Beschluss verfällt.
+
+2~a5 A.5. Verfall
+
+Wenn innerhalb von 4 Wochen ein vorgeschlagener Beschluss nicht diskutiert, nicht abgeändert, darüber abgestimmt oder auf andere Weise behandelt wurde, kann der Schriftführer eine Erklärung abgeben, dass man dabei ist, die Angelegenheit zurückzuziehen. Wenn keiner der Befürworter der Anträge innerhalb einer Woche Einwände erhebt, wird die Angelegenheit zurückgezogen.
+
+Der Schriftführer kann seiner Erklärung, falls angebracht, auch Vorschläge beifügen, wie man weiter vorgehen soll.
+
+2~a6 A.6. Stimmenzählung
+
+# Der Stimmzettel jedes Abstimmenden rangiert die Wahlmöglichkeiten (d.h.: ordnet ihnen einen Rang zu), über die abgestimmt wird. Nicht alle Wahlmöglichkeiten müssen rangiert werden. Rangierte Wahlmöglichkeiten werden als bevorzugt gegenüber allen nicht rangierten Wahlmöglichkeiten betrachtet. Die Abstimmenden können Wahlmöglichkeiten gleichrangig rangieren. Nicht rangierte Wahlmöglichkeiten werden als einander gleichrangig betrachtet. Einzelheiten darüber, wie Stimmzettel ausgefüllt werden können, werden mit in den Aufruf zur Abstimmung aufgenommen.
+
+# Falls der Wahlzettel ein Quorum R fordert, werden alle Wahlmöglichkeiten (außer der Vorgabe-Wahlmöglichkeit), die nicht mindestens R Stimmen erhalten, die diese Wahlmöglichkeit gegenüber der Vorgabe-Wahlmöglichkeit höher rangieren, fallen gelassen.
+
+# Jede (nicht-Vorgabe-) Wahlmöglichkeit, die die Vorgabe-Wahlmöglichkeit nicht mit ihrem benötigten Mehrheitsverhältnis überstimmt, wird fallengelassen.
+
+_# Sind zwei Wahlmöglichkeiten A und B gegeben, so ist V(A,B) die Anzahl der Abstimmenden, die Wahlmöglichkeit A gegenüber Wahlmöglichkeit B bevorzugen.
+
+_# Eine Wahlmöglichkeit A besiegt die Vorgabe-Wahlmöglichkeit D mit einem Mehrheitsverhältnis N, falls V(A,D) echt größer als N * V(D,A) ist.
+
+_# Wenn eine Supermajorität von S:1 für A benötigt wird, beträgt ihr Mehrheitsverhältnis S; im anderen Fall ist ihr Mehrheitsverhältnis 1.
+
+# Aus der Liste von nicht fallengelassenen Wahlmöglichkeiten erzeugen wir eine Liste von paarweisen Besiegungen.
+
+_# Eine Wahlmöglichkeit A besiegt eine Wahlmöglichkeit B, falls V(A,B) echt größer als V(B,A) ist.
+
+# Aus der Liste der paarweisen Besiegungen erzeugen wir eine Liste von transitiven Besiegungen.
+
+_# Eine Wahlmöglichkeit A besiegt eine Wahlmöglichkeit C transitiv, falls A C besiegt oder es eine andere Wahlmöglichkeit B gibt, so dass A B besiegt UND B transitiv C besiegt.
+
+# Wir konstruieren die Schwartzsche Menge aus der Menge der transitiven Besiegungen.
+
+_# Eine Wahlmöglichkeit A ist in der Schwartzschen Menge, falls für alle Wahlmöglichkeiten B entweder A transitiv B besiegt, oder B nicht transitiv A besiegt.
+
+# Wenn es Besiegungen zwischen Wahlmöglichkeiten gibt, die in der Schwartzschen Menge liegen, so lassen wir die schwächste solcher Besiegungen aus der Liste der paarweisen Besiegungen fallen und kehren zu Schritt 5 zurück.
+
+_# Eine Besiegung (A,X) ist schwächer als eine Besiegung (B,Y) falls V(A,X) kleiner als V(B,Y) ist. Außerdem ist (A,X) schwächer als (B,Y) falls V(A,X) gleich V(B,Y) ist, und V(X,A) größer als V(Y,B) ist.
+
+_# Eine schwächste Besiegung ist eine Besiegung, die keine andere schwächere Besiegung besitzt. Es kann mehr als eine solche Besiegung geben.
+
+# Falls es keine Besiegungen in der Schwartzschen Menge gibt, wird der Sieger aus den Wahlmöglichkeiten in der Schwartzschen Menge ausgewählt. Falls es nur eine solche Wahlmöglichkeit gibt, ist sie der Sieger. Falls es mehrere Wahlmöglichkeiten gibt, bestimmt der Stimmberechtigte mit der ausschlaggebenden Stimme, welche der Wahlmöglichkeiten siegt.
+
+Anmerkung: Wahlmöglichkeiten, welche die Abstimmenden über die Vorgabe-Wahlmöglichkeit rangieren, sind Wahlmöglichkeiten, die sie annehmbar finden. Unter die Vorgabe-Wahlmöglichkeit rangierte Wahlmöglichkeiten sind Wahlmöglichkeiten, die sie nicht annehmbar finden.
+
+Wenn das Standard-Beschlussverfahren benutzt werden soll, muss der darauf bezugnehmende Text bestimmen, was ausreicht, um einen Beschlussentwurf einzubringen und/oder zu befürworten, wie lange die Mindestfrist für Diskussionen dauert, und wie lange die Abstimmungsfrist dauert. Er muss auch jegliche Supermajorität und/oder das Quorum (und Vorgabe-Wahlmöglichkeit) bestimmen, die zu verwenden sind.
+
+1~b B. Sprachgebrauch und Typographie
+
+Der Präsens Indikativ (zum Beispiel ist) bedeutet, dass die Aussage eine Vorschrift in dieser Verfassung ist. Darf oder kann zeigt an, dass es im Ermessen der Person oder des Organs liegt. Sollte bedeutet, dass es als gute Sache betrachtet würde, wenn der Satz befolgt würde, aber er ist nicht bindend. Als Zitat markierter Text, so wie dieser, stellt nur Beweggründe dar, und bildet keinen Teil der Verfassung. Er darf nur dazu benutzt werden, um in Zweifelsfällen bei der Interpretation zu helfen.
+
+Anmerkung des Übersetzers: Obwohl diese Übersetzung mit Sorgfalt erstellt wurde, ist nur der englische Originaltext dieser Verfassung verbindlich.
+
+
+
+% Dies ist die am 24. September 2006 ratifizierte
+% Version 1.3. Sie ersetzt die am 29. Oktober 2003
+% ratifizierte Version 1.2 und die am 21. Juni 2003
+% ratifizierte Version 1.1, welche ihrerseits die am
+% 2. Dezember 1998 ratifizierte Version 1.0 ersetzt.
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1.sst
new file mode 100644
index 00000000..2add6ea9
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1.sst
@@ -0,0 +1,136 @@
+% SiSU 2.0
+
+@title: Debian Social Contract
+ :subtitle: (v1.1)
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:policy:social contract;GNU/Linux:debian:social contract
+
+@date:
+ :published: 2004-04-26
+ :created: 1997-07-05
+ :issued: 1997-07-05
+ :valid: 2004-04-26
+ :available: 2004-04-26
+ :modified: 2004-04-26
+
+@language:
+ :document: English
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license <br>"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc.
+ :license: This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/social_contract
+ {Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
+
+@make:
+ :breaks: new=C; break=1
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Debian Social Contract
+
+1~pre [Prefix]-#
+
+Version 1.1 ratified on April 26, 2004. Supersedes {Version 1.0}http://www.debian.org/social_contract.1.0 ratified on July 5, 1997.
+
+Debian, the producers of the Debian GNU/Linux system, have created the *{Debian Social Contract}*. The {Debian Free Software Guidelines (DFSG)}http://www.debian.org/social_contract#guidelines 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.}http://www.opensource.org/docs/definition_plain.html
+
+1~ Social Contract with the Free Software Community
+
+2~ 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~ 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.
+
+2~ 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.
+
+2~ 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.
+
+2~ 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).
+
+1~ The Debian Free Software Guidelines (DFSG)
+
+2~ 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~ 2. Source Code
+
+The program must include source code, and must allow distribution in source code as well as compiled form.
+
+2~ 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.
+
+2~ 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.)
+
+2~ 5. No Discrimination Against Persons or Groups
+
+The license must not discriminate against any person or group of persons.
+
+2~ 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.
+
+2~ 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.
+
+2~ 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.
+
+2~ 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.
+
+2~ 10. Example Licenses
+
+The {"GPL"}http://www.debian.org/social_contract.1.0, {"BSD"}http://www.debian.org/misc/bsd.license, and {"Artistic"}http://www.perl.com/pub/a/language/misc/Artistic.html 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}http://lists.debian.org/debian-announce/debian-announce-1997/msg00017.html 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".}http://www.opensource.org/docs/definition.php }/
+
+/{Other organizations may derive from and build on this document. Please give credit to the Debian project if you do.}/
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~da.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~da.sst
new file mode 100644
index 00000000..c22f142b
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~da.sst
@@ -0,0 +1,138 @@
+% SiSU 2.0
+
+@title: Debians sociale kontrakt
+ :subtitle: Debian Social Contract (v1.1)
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:policy:social contract;GNU/Linux:debian:social contract;language:Danish
+
+@date:
+ :published: 2004-04-26
+ :created: 1997-07-05
+ :issued: 1997-07-05
+ :valid: 2004-04-26
+ :available: 2004-04-26
+ :modified: 2004-04-26
+
+@language:
+ :document: Danish
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.da.html <br>"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc.
+ :license: This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/social_contract
+ {Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
+
+@make:
+ :breaks: new=C; break=1
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Debians sociale kontrakt
+
+1~pre [Prefix]-#
+
+Version 1.1 blev vedtaget den 26. april 2004. Den erstattede version 1.0, som blev vedtaget den 5. juli 1997.
+
+Debian, der fremstiller Debian GNU/Linux-systemet, har skrevet Debians sociale kontrakt. Debians retningslinier for fri software (DFSG)-delen af kontrakten, oprindeligt et sæt løfter som vi er enige om at overholde, har fri software-fællesskabet taget til sig som basis for Open Source-definitionen (åben kildekode-definitionen).
+
+1~ Social kontrakt med fri software-fællesskabet
+
+2~ 1. Debian vil forblive 100 procent fri software
+
+De retningslinier vi bruger for at afgøre om et værk er "frit" stiller vi til rådighed i dokumentet "The Debian Free Software Guidelines", på dansk "Debians retningslinier for fri software". Vi lover at Debian-systemet og alle dets komponenter vil være frit tilgængelige jævnfør disse retningslinier. Vi vil støtte folk der udvikler og anvender både frie og ikke-frie værker på Debian. Vi vil aldrig lade systemet kræve anvendelse af et ikke-frit komponent.
+
+2~ 2. Vi vil give noget tilbage til fri software-fællesskabet
+
+Når vi udvikler nye komponenter til Debian-systemet, vil vi licensere dem på en måde som er i overensstemmelse med Debian retningslinier for fri software. Vi vil lave det bedste system vi kan, således at frit tilgængelige værker får stor udbredelse og anvendelse. Vi vil videregive ting så som fejlrettelser, forbedringer og brugerønsker til "opstrøms"-udviklerne af værker indeholdt i vores system.
+
+2~ 3. Vi vil ikke skjule problemer
+
+Hele vores database over fejlrapporter vil altid være åben for offentligheden. Rapporter som indsendes via Internet, vil med det samme kunne ses af andre.
+
+2~ 4. Vi prioriterer vore brugere og fri software højest
+
+Vi styres af brugernes og fri software-fællesskabets behov. Vi vil prioritere deres interesser højest. Vi vil understøtte vore brugeres behov for at kunne anvende mange forskellige computer-miljøer. Vi vil ikke gøre indsigelser mod ikke-frie værker der er beregnet til at køre på på Debian-systemer, eller forsøge at opkræve en afgift fra folk der udvikler eller anvender sådanne systemer. Vi vil tillade andre at fremstille distibutioner som indeholder både Debian-systemet og andre værker, uden at opkræve afgifter for det. For at fremme disse mål, vil vi stille et integreret system bestående af høj kvalitetsmateriale til rådighed, uden juridiske begrænsninger der kan forhindre sådanne anvendelser af systemet.
+
+2~ 5. Værker der ikke lever op til vore fri software-standarder
+
+Vi anerkender at nogle af vore brugere behøver programmer som ikke opfylder Debians retningslinier for fri software. Til det formål har vi oprettet områderne "contrib" (bidrag) og "non-free" (ikke-frit) i vores filarkiv. Pakkerne i disse områder udgør ikke en del af Debian-systemet, selvom de er opsat til brug sammen med Debian. Vi opfordrer cd-producenter til at læse licensbetingelser til pakkerne i disse områder og afgøre om de kan distribuere pakkerne på deres cd'er. Derfor, selvom ikke-frie værker ikke er en del af Debian, understøtter vi anvendelsen af dem og vi stiller infrastrukturen (som for eksempel vores fejlrapporteringssystem og postlister) til rådighed for ikke-frie pakker.
+
+1~ Debians retningslinier for fri software (DFSG)
+
+2~ 1. Fri videredistribution
+
+Et Debian-komponents licens må ikke forhindre nogen i at sælge eller forære programmet væk som en komponent i en samlet distribution, bestående af programmer fra flere forskellige kilder. Licensen må ikke kræve licenseringsafgifter eller lignende ved et sådant salg.
+
+2~ 2. Kildekode
+
+Programmet skal inkludere kildekode, og skal tillade distribution i form af både kildekode og et oversat program.
+
+2~ 3. Afledte værker
+
+Licensen skal tillade ændringer og afledte værker, og skal tillade at disse distribueres under de samme betingelser som det originale programs licens.
+
+2~ 4. Forfatterens kildekodes integritet
+
+Licensen må _kun_ begrænse distribuering af kildekoden i ændret form, hvis licensen tillader distribuering af "patch-filer" sammen med kildekoden med det formål at ændre programmet under oversættelse. Licensen skal eksplicit tillade distribution af programmer baseret på den ændrede kildekode. Licensen kan kræve at afledte værker har et andet navn eller versionsnummer end det originale program. (Dette er et kompromis. Debian-gruppen opfordrer alle forfattere til ikke at begrænse ændring af nogen filer, hverken kildekode eller oversat program.)
+
+2~ 5. Ingen diskrimination af personer eller grupper
+
+Licensen må ikke diskriminere nogen person eller gruppe af personer.
+
+2~ 6. Ingen diskrimination af anvendelsesområdet
+
+Licensen må ikke forhindre nogen i at bruge programmet indenfor et specifikt anvendelsesområde. Den må for eksempel ikke forhindre at programmet anvendes kommercielt eller i forbindelse med genetisk forskning.
+
+2~ 7. Distribution af licensen
+
+Rettighederne knyttet til programmet skal gælde alle, som programmet er videredistribueret til, uden at kræve yderligere licensering for disse parter.
+
+2~ 8. Licensen må ikke kun gælde Debian
+
+Rettighederne knyttet til programmet skal ikke være afhængig af at programmet er en del af Debian-systemet. Hvis programmet tages fra Debian og anvendes eller distribueres uden Debian, men ellers indenfor licensbetingelserne, skal alle parter som programmet er videredistribueret til, have de samme rettigheder som de licensbetingelser, der gives i forbindelse med Debian-systemet.
+
+2~ 9. Licensen må ikke smitte anden software
+
+Licensen må ikke lægge restriktioner på anden software som distribueres sammen med den licenserede software. For eksempel må licensen ikke insistere på, at alle andre programmer der distribueres på det samme medie er fri software.
+
+2~ 10. Eksempler på licenser
+
+"GPL"-, "BSD"-, og "Artistic"-licenserne er eksempler på licenser som vi betragter som værende "frie".
+
+Ean Schuessler foreslog at nedfælde vores "sociale kontrakt med fri software-fællesskabet". Det første udkast blev skrevet af Bruce Perens og blev fuldstændiggjort af de andre Debian-udviklere i løbet af en månedlang e-mail-konference i juni 1997, og dernæst accepteret som Debian-projektets offentlige retningslinier.
+
+Bruce Perens fjernede senere de Debian-specifikke referencer fra "Debians retningslinier for fri software", for at forfatte “Open Source-definitionen”.
+
+Andre organisationer må låne fra og basere sig på dette dokument. Angiv i givet fald venligst Debian-projektet som kilde.
+
+Tilbage til Debian-projektets hjemmeside.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~de.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~de.sst
new file mode 100644
index 00000000..c0db5758
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~de.sst
@@ -0,0 +1,139 @@
+% SiSU 2.0
+
+@title: Debian-Gesellschaftsvertrag
+ :subtitle: Debian Social Contract
+ :edition: v1.1
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:policy:social contract;GNU/Linux:debian:social contract;language:German
+
+@date:
+ :published: 2004-04-26
+ :created: 1997-07-05
+ :issued: 1997-07-05
+ :valid: 2004-04-26
+ :available: 2004-04-26
+ :modified: 2004-04-26
+
+@language:
+ :document: German
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.de.html <br>Dieses Material darf nur unter den Bestimmungen, die in der Open Publication License, Draft v1.0 oder später (Sie können unsere lokale Kopie lesen http://www.debian.org/opl, die neuste Version ist normalerweise unter unter http://www.opencontent.org/openpub/ verfügbar) festgehalten sind, weitergegeben werden. <br>Dies ist die deutsche Übersetzung von "Debian's license" http://www.debian.org/license.en.html. In Zweifelsfällen ist das englische Original maßgeblich.
+ :license: "Debian" und das Debian-Logo http://www.debian.org/logos/ sind Warenzeichen von Software in the Public Interest, Inc.
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/social_contract
+ {Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
+
+@make:
+ :breaks: new=C; break=1
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Debian-Gesellschaftsvertrag
+
+1~pre [Prefix]-#
+
+Dies ist die am 26. April 2004 ratifizierte Version 1.1. Sie ersetzt die am 5. Juli 1997 ratifizierte Version 1.0.
+
+Debian, die Hersteller des Systems Debian GNU/Linux, haben den »Gesellschaftsvertrag« aufgestellt. Die Debian-Richtlinien für Freie Software (DFSG), Teil dieses Vertrages und ursprünglich als eine Menge an Verpflichtungen entwickelt, denen wir zustimmen, wurden von der Free-Software-Community als Basis der Open-Source-Definition übernommen.
+
+1~ »Gesellschaftsvertrag« mit der Gemeinschaft für Freie Software
+
+2~ 1. Debian wird zu 100% frei bleiben
+
+Wir geben die Richtlinien, die wir verwenden, um zu bestimmen ob eine Arbeit »frei« ist, in dem »Die Debian-Richtlinien für Freie Software« genannten Dokument an. Wir versprechen, dass das Debian-System und alle dessen Komponenten entsprechend diesen Richtlinien frei sein werden. Wir werden Personen unterstützen, die freie und unfreie Arbeiten zu Debian erzeugen oder verwenden. Wir werden niemals das System von nicht-freien Komponenten abhängig machen.
+
+2~ 2. Unser Beitrag zur Gemeinschaft für Freie Software
+
+Wenn wir neue Komponenten des Debian-Systems schreiben, so werden wir sie auf eine Art lizenzieren, die in Einklang mit den Debian-Richtlinien für Freie Software steht. Wir werden das uns bestmögliche System erstellen, so dass Freie Arbeiten weit verbreitet und genutzt werden. Wir werden Dinge wie Korrekturen, Verbesserungen und Anwenderwünsche an die ursprünglichen (»upstream«) Autoren weiterleiten, deren Arbeiten in unser System integriert wurden.
+
+2~ 3. Wir werden Probleme nicht verbergen
+
+Wir werden unsere Fehlerdatenbank für alle Zeiten öffentlich betreiben. Fehlermeldungen, die von Personen online abgeschickt werden, werden unverzüglich für andere sichtbar.
+
+2~ 4. Unsere Prioritäten sind unsere Anwender und Freie Software
+
+Wir orientieren uns an den Bedürfnissen unserer Anwender und der Gemeinschaft für Freie Software. Deren Interessen stehen an erster Stelle. Wir werden unsere Nutzer bei ihrer Arbeit mit den verschiedensten Rechnerumgebungen unterstützen. Wir haben nichts gegen unfreie Arbeiten die darauf abzielen, auf Debian-Systemen verwendet zu werden, oder versuchen eine Gebühr von Personen, die solche Arbeiten erstellen oder verwenden, einzufordern. Wir erlauben anderen, Distributionen zu erstellen, die das Debian-System und andere Arbeiten enthalten, ohne dafür irgendwelche Gebühren zu erheben. Um diese Ziele zu fördern, werden wir ein integriertes System von hoher Qualität anbieten, das die gerade beschriebene Nutzung nicht durch rechtliche Einschränkungen verhindert.
+
+2~ 5. Arbeiten, die nicht unseren Standards für Freie Software genügen
+
+Wir wissen, dass einige unserer Anwender unbedingt Arbeiten einsetzen müssen, die nicht den Debian-Richtlinien für Freie Software entsprechen. Für solche Arbeiten haben wir die Bereiche »contrib« und »non-free« in unserem Archiv eingerichtet. Die Pakete in diesen Bereichen sind nicht Bestandteil des Debian-Systems, wurden aber trotzdem für den Einsatz mit Debian vorbereitet. Wir empfehlen den CD-Herstellern, die jeweiligen Lizenzbestimmungen der Pakete in diesen Bereichen zu studieren und selbst zu entscheiden, ob sie die Pakete mit ihren CDs verteilen dürfen. Obwohl unfreie Arbeiten nicht Bestandteil von Debian sind, unterstützen wir ihren Einsatz und bieten Infrastruktur für nicht freie Pakete an (z.B. unsere Fehlerdatenbank und die Mailinglisten).
+
+1~ Die Debian-Richtlinien für Freie Software (DFSG)
+
+2~ 1. Unbeschränkte Weitergabe
+
+Ein Bestandteil der Debian-Distribution darf durch seine Lizenz nicht verhindern, dass irgendjemand diese Software als Bestandteil einer Software-Distribution, die Programme aus den verschiedensten Quellen enthält, verkauft oder weitergibt. Die Lizenz darf keine Abgaben oder sonstige Leistungen für einen solchen Verkauf fordern.
+
+2~ 2. Quellcode
+
+Das Programm muss im Quellcode vorliegen, und es muss die Weitergabe sowohl im Quellcode als auch in kompilierter Form erlaubt sein.
+
+2~ 3. Weiterführende Arbeiten
+
+Die Lizenz muss Veränderungen und weiterführende Arbeiten gestatten und es erlauben, dass diese unter den gleichen Lizenzbedingungen weitergegeben werden dürfen wie die Original-Software.
+
+2~ 4. Integrität des ursprünglichen Quellcodes
+
+Die Lizenz darf die Weitergabe von verändertem Quellcode nur dann verbieten, wenn sie die Weitergabe von so genannten Patch-Dateien mit dem Quellcode erlaubt, die dazu dienen, das Programm vor seiner Herstellung zu modifizieren. Die Lizenz muss ausdrücklich die Weitergabe der aus dem veränderten Quellcode erzeugten Programme erlauben. Die Lizenz darf fordern, dass die veränderten Programme einen anderen Namen oder eine andere Versionsnummer tragen müssen. (Dies ist ein Kompromiss. Die Debian-Gruppe ermutigt alle Autoren, Veränderungen an Dateien sowohl im Quellcode als auch in Binärform zu erlauben.)
+
+2~ 5. Keine Diskriminierung von Personen oder Gruppen
+
+Die Lizenz darf keine Person oder Gruppe von Personen diskriminieren.
+
+2~ 6. Keine Diskriminierung von Einsatzbereichen
+
+Die Lizenz darf keine Einschränkungen hinsichtlich des Einsatzbereichs vornehmen. Beispielsweise darf sie nicht verhindern, dass das Programm geschäftlich oder für genetische Forschungen verwendet wird.
+
+2~ 7. Weitergabe der Lizenz
+
+Die mit einem Programm verbundenen Rechte müssen für alle gelten, die das Programm erhalten, ohne dass es für sie notwendig ist, eine zusätzliche Lizenz zu erwerben.
+
+2~ 8. Keine spezielle Lizenz für Debian
+
+Die mit dem Programm verbundenen Rechte dürfen nicht davon abhängig sein, dass das Programm Teil des Debian-Systems ist. Falls das Programm aus der Debian-Distribution herausgenommen wird und ohne Debian genutzt oder vertrieben werden soll, ansonsten aber im Rahmen der Programmlizenz bleibt, so müssen alle Parteien, die das Programm bekommen, die gleichen Rechte haben, wie sie im Zusammenhang mit dem Debian-System gewährt wurden.
+
+2~ 9. Keine Auswirkungen auf andere Programme
+
+Die Lizenz darf keine Beschränkungen besitzen, die Auswirkungen auf andere Software hat, die mit diesem Programm weitergegeben wird. Beispielsweise darf die Lizenz nicht vorschreiben, dass alle anderen Programme auf dem gleichen Medium Freie Software sein müssen.
+
+2~ 10. Beispiellizenzen
+
+Die »GPL«, »BSD« und »Artistic« Lizenzen sind Beispiele für Lizenzen, die wir als »frei« betrachten.
+
+Das Konzept, unseren »Gesellschaftsvertrag mit der Gemeinschaft für freie Software« aufzustellen, wurde von Ean Schuessler vorgeschlagen. Dieses Dokument wurde von Bruce Perens entworfen und von den anderen Debian-Entwicklern in einer einmonatigen E-Mail-Konferenz im Juni 1997 verfeinert, bevor es dann als öffentliche Richtlinie des Debian-Projekts akzeptiert wurde.
+
+Bruce Perens entfernte später die Debian-spezifischen Teile aus den Debian-Richtlinien für Freie Software um »Die Open-Source Definition« zu erstellen.
+
+Andere Organisationen können von diesem Dokument ableiten oder auf ihm aufbauen. Bitte erwähnen Sie das Debian-Projekt als Quelle, wenn Sie dies tun.
+
+Dies ist die deutsche Übersetzung von »Debian's social contract with the free software community«. In Zweifelsfällen ist das englische Original maßgeblich.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~es.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~es.sst
new file mode 100644
index 00000000..8625fce9
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~es.sst
@@ -0,0 +1,136 @@
+% SiSU 2.0
+
+@title: Contrato social de Debian
+ :subtitle: Debian Social Contract (v1.1)
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:policy:social contract;GNU/Linux:debian:social contract;language:Spanish
+
+@date:
+ :published: 2004-04-26
+ :created: 1997-07-05
+ :issued: 1997-07-05
+ :valid: 2004-04-26
+ :available: 2004-04-26
+ :modified: 2004-04-26
+
+@language:
+ :document: Spanish
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.es.html <br>"Debian" y el logotipo de Debian http://www.debian.org/logos/ son marcas registradas de Software in the Public Interest, Inc.
+ :license: OJO: Esta es una traducción de la licencia original, y no tiene ningún valor jurídico http://www.debian.org/license.en.html. Si desea ver la versión verdadera debe acudir a la licencia original, en este mismo servidor.<br>Este material sólo puede ser distribuido sujeto a los términos y condiciones indicados en la Licencia de publicaciones abiertas, borrador v1.0 o posterior (puede consultar nuestra copia local http://www.debian.org/opl ; la última versión suele estar disponible en http://www.opencontent.org/openpub/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/social_contract
+ {Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
+
+@make:
+ :breaks: new=C; break=1
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Contrato social de Debian
+
+1~pre [Prefix]-#
+
+La versión 1.1 ratificada el 26 de abril de 2004 deroga la versión 1.0 ratificada el 5 de julio de 1997.
+
+El proyecto Debian, creador del sistema Debian GNU/Linux, ha creado el contrato social de Debian. Este documento es una declaración de intenciones por nuestra parte y un conjunto de principios que acatamos. La parte del contrato llamada directrices de software libre de Debian (Debian Free Software Guidelines, DFSG)— diseñada inicialmente como un un conjunto de criterios para definir lo que es software libre—, ha sido adoptada posteriormente por la comunidad de software libre como base para la definición de Open Source.
+
+1~ «Contrato social» con la comunidad de software libre
+
+2~ 1. Debian permanecerá 100% libre
+
+Las «Las directrices de software libre de Debian» (DFSG) son el criterio que nosotros utilizamos para determinar si el software es «libre» o no. Prometemos mantener el sistema GNU/Linux así como todos sus componentes completamente libres de acuerdo con este criterio. No obstante, daremos soporte también a aquellos usuarios que desarrollen y ejecuten software no libre en Debian pero nunca haremos que el sistema tenga que utilizar obligatoriamente un componente que no sea libre.
+
+2~ 2. Contribuiremos a la comunidad de software libre
+
+Cuando escribamos nuevos componentes del sistema Debian, los licenciaremos de forma consistente con nuestra definición de software libre. Haremos el mejor sistema que podamos, de forma que el software libre tenga amplia difusión y uso. Enviaremos parches, mejoras, peticiones de los usuarios, etc a los autores originales (esto se conoce en inglés como upstream, N. del T.) del software incluido en nuestro sistema.
+
+2~ 3. No ocultaremos los problemas
+
+Mantendremos nuestra base de datos de informes de error accesible al público en todo momento. Los informes de error que los usuarios envíen serán visibles por el resto de usuarios de forma inmediata.
+
+2~ 4. Nuestra prioridad son nuestros usuarios y el software libre
+
+Nos guiaremos por las necesidades de nuestros usuarios y de la comunidad del software libre. Sus intereses serán una prioridad para nosotros. Daremos soporte a las necesidades de nuestros usuarios para que puedan trabajar en muchos tipos distintos de entornos de trabajo. No pondremos objeciones al software no libre que vaya a ejecutarse sobre Debian ni cobraremos a las personas que quieran desarrollar o usar ese tipo de software (no libre). Permitiremos a otros crear distribuciones de valor añadido basadas en Debian sin cobrarles nada por ello. Es más, entregaremos un sistema integrado de alta calidad sin restricciones legales que pudieran prevenir este tipo de uso.
+
+2~ 5. Trabajos que no siguen nuestros estándares de software libre
+
+Reconocemos que algunos de nuestros usuarios necesitan usar trabajos que no sigan las directrices de software libre de Debian (DFSG). Por ello, hemos creado las secciones «contrib» y «non-free» en nuestro archivo para estos trabajos. Los paquetes en estas secciones no son parte del sistema Debian, aunque ha sido configurado para usarse con Debian. Animamos a los distribuidores de CDs a que lean las licencias de los paquetes en estas secciones para poder determinar si pueden distribuir este software en sus CDs. Así pues, aunque los trabajos que no sean libres no son parte de Debian, damos soporte para su uso, y proporcionamos infraestructuras (como nuestro sistema de informe de errores y listas de distribución) para paquetes no libres.
+
+1~ Las directrices de software libre de Debian (DFSG)
+
+2~ 1. Libre redistribución
+
+La licencia de un componente de Debian no puede restringir a un tercero el vender o entregar el programa como parte de una distribución mayor que contiene programas de diferentes fuentes. La licencia no debe solicitar «royalties» u otras comisiones para esta venta.
+
+2~ 2. Código fuente
+
+El programa debe incluir el código fuente completo, y debe permitir la distribución en forma de código fuente y en forma compilada (binario).
+
+2~ 3. Trabajos derivados
+
+La licencia debe permitir modificaciones y trabajos derivados y debe permitir que estos se distribuyan bajo los mismos términos que la licencia del programa original.
+
+2~ 4. Integridad del código fuente del autor
+
+La licencia puede restringir la distribución del código fuente en forma modificada *sólo* si la licencia permite la distribución de «parches» («patch files») para poder modificar el código fuente original del programa en el momento de compilarlo. La licencia debe permitir explícitamente la distribución de software a partir de código fuente modificado. La licencia puede obligar a los trabajos derivados a llevar un nombre o número de versión diferentes del programa original (Esto es un compromiso. El grupo de Debian anima a todos los autores a no restringir ningún fichero, fuente o compilado, de ser modificado.)
+
+2~ 5. No discriminación contra personas o grupos
+
+La licencia no debe discriminar a ninguna persona o grupo de personas.
+
+2~ 6. No discriminación en función de la finalidad perseguida
+
+La licencia no puede restringir el uso del programa para una finalidad determinada. Por ejemplo, no puede restringir el uso del programa a empresas con fines comerciales, o en investigación genética.
+
+2~ 7. Distribución de la licencia
+
+Los derechos y libertades de uso asociados al programa deben aplicarse en la misma forma a todos aquellos a los que se redistribuya el programa, sin necesidad de pedir una licencia adicional para estas terceras partes.
+
+2~ 8. La licencia no ha de ser específica para Debian
+
+Los derechos asociados al programa no deben depender de que el programa sea parte o no del sistema Debian. Si el programa es extraído de Debian y usado o distribuido sin Debian, pero manteniendo el resto de las condiciones de la licencia, todos aquellos a los que el programa se redistribuya deben tener los mismos derechos que los dados cuando forma parte de Debian.
+
+2~ 9. La licencia no debe contaminar a otros programas
+
+La licencia no debe poner restricciones sobre otros programas que se distribuyan junto con el programa licenciado. Por ejemplo, la licencia no puede insistir que todos los demás programas distribuidos sobre el mismo medio deben ser software libre.
+
+2~ 10. Ejemplos de licencias
+
+Las licencias «GPL», «BSD», y « Artística» son ejemplos de licencias que nosotros consideramos «libres».
+
+La expresión «contrato social con la comunidad de software libre» fue sugerida por Ean Schuessler. El primer borrador de este documento fue escrito por Bruce Perens, fue modificado por los demás desarrolladores de Debian durante una conferencia por correo electrónico que duró un mes (junio de 1997) y finalmente aceptado como la normativa pública del proyecto Debian.
+
+Posteriormente, Bruce Perens eliminó las referencias específicas a Debian en las directrices de Debian para el Software Libre (DFSG), creando “la definición de Open Source”.
+
+Cualquier otra organización puede llevar a cabo trabajos derivados a partir de este documento. Por favor, haga referencia al proyecto Debian en tal caso.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~fi.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~fi.sst
new file mode 100644
index 00000000..0f66e192
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~fi.sst
@@ -0,0 +1,138 @@
+% SiSU 2.0
+
+@title: Debianin yhteisösopimus
+ :subtitle: Debian Social Contract (v1.1)
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:policy:social contract;GNU/Linux:debian:social contract;language:Finnish
+
+@date:
+ :published: 2004-04-26
+ :created: 1997-07-05
+ :issued: 1997-07-05
+ :valid: 2004-04-26
+ :available: 2004-04-26
+ :modified: 2004-04-26
+
+@language:
+ :document: Finnish
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.fi.html <br>"Debian" ja Debian-logo http://www.debian.org/logos/ ovat Software in the Public Interest, Inc.:n tavaramerkkejä.<br> http://www.debian.org/license.en.html
+ :license: Tätä materiaalia voidaan levittää ainoastaan Open Publication License, vedos v1.0 (paikallinen kopiomme luettavaksesi http://www.debian.org/opl ) tai myöhemmän määräysten ja ehtojen mukaisesti. Uusin versio on saatavilla yleensä osoitteesta http://www.opencontent.org/.
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/social_contract
+ {Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
+
+@make:
+ :breaks: new=C; break=1
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Debianin yhteisösopimus
+
+1~pre [Prefix]-#
+
+Versio 1.1 ratifioitiin 26. huhtikuuta 2004. Se korvaa version 1.0, joka ratifioitiin 5. heinäkuuta 1997.
+
+Debian, joka koostuu Debian GNU/Linux -järjestelmän tekijöistä, on luonut Debianin yhteisösopimuksen. Sen osan sopimuksesta, joka tunnetaan nimellä Debianin vapaiden ohjelmistojen ohjeisto (Debian Free Software Guidelines (DFSG)) ja jonka oli alun perin tarkoitus määrittää joukko sitoumuksia, jotka aiomme pitää, on vapaiden ohjelmistojen yhteisö ottanut Open Source -määritelmän pohjaksi.
+
+1~ Yhteisösopimus vapaiden ohjelmistojen yhteisön kanssa
+
+2~ 1. Debian pysyy täysin vapaana
+
+Olemme luoneet ohjeiston nimeltään Debianin vapaiden ohjelmistojen ohjeisto (Debian Free Software Guidelines, DFSG), jonka perusteella määrittelemme milloin jokin teos on vapaa. Lupaamme, että Debian-järjestelmä kaikkine osineen on vapaa kyseisen ohjeiston määrittelemässä mielessä. Tuemme ihmisiä, jotka luovat tai käyttävät sekä vapaita että epävapaita teoksia Debian-järjestelmässä. Emme koskaan muuta järjestelmää sellaiseksi, että se edellyttäisi epävapaiden osien käyttämistä.
+
+2~ 2. Annamme takaisin vapaiden ohjelmistojen yhteisölle
+
+Kun teemme Debian-järjestelmään uusia osia, lisensoimme ne Debianin vapaiden ohjelmistojen ohjeiston mukaisesti. Teemme niin hyvän järjestelmän kuin suinkin pystymme, jotta vapaita teoksia levitettäisiin ja käytettäisiin laajalti. Välitämme korjaukset, parannukset ja käyttäjien toiveet "ylävirtaan" eli järjestelmäämme sisältyvien teosten tekijöille.
+
+2~ 3. Emme kätke ongelmia
+
+Pidämme vikailmoitustietokantamme jatkuvasti kaikkien nähtävillä. Sähköisesti toimitetut vikailmoitukset tulevat ripeästi muiden nähtäville.
+
+2~ 4. Käyttäjämme ja vapaat ohjelmistot ovat tärkeimmät prioriteettimme
+
+Käyttäjiemme ja vapaiden ohjelmistojen yhteisön tarpeet ohjaavat meitä, ja asetamme nämä tarpeet ensimmäiselle sijalle. Tuemme käyttäjiemme tarpeita monenlaisissa tietojenkäsittely-ympäristöissä. Emme vastusta Debian-järjestelmissä käytettäväksi tarkoitettuja epävapaita teoksia emmekä yritä periä maksua henkilöiltä, jotka luovat tai käyttävät sellaisia teoksia. Sallimme muiden luoda ilman maksua käyttöjärjestelmäjakeluita, joihin sisältyy sekä Debian-järjestelmä että muita teoksia. Näiden tavoitteiden edistämiseksi tarjoamme korkealaatuisista, keskenään hyvin toimivista osista muodostuvan järjestelmän ilman mitään lakiin perustuvia rajoituksia, jotka voisivat estää edellä kuvatun mukaisen käytön.
+
+2~ 5. Teokset, jotka eivät täytä vapaiden ohjelmistojen vaatimuksiamme
+
+Tiedostamme, että joidenkin käyttäjiemme on välttämätöntä käyttää teoksia, jotka eivät vastaa Debianin vapaiden ohjelmistojen ohjeiston vaatimuksia. Tällaisia teoksia varten olemme luoneet tiedostoarkistoomme "contrib"- ja "non-free"-osiot. Näihin osioihin kuuluvat paketit eivät ole osa Debian-järjestelmää, vaikka ne onkin mukautettu toimimaan Debianissa. Kannustamme CD-valmistajia lukemaan näissä osioissa olevien pakettien lisenssiehdot ja selvittämään, voivatko he levittää kyseisiä paketteja CD-levyillään. Näin ollen, vaikka epävapaat teokset eivät kuulu Debianiin, tuemme niiden käyttöä ja tarjoamme epävapaiden pakettien tueksi infrastruktuurin (kuten vianseurantajärjestelmän ja sähköpostilistat).
+
+1~ Debianin vapaiden ohjelmistojen ohjeisto (DFSG)
+
+2~ 1. Vapaa levitys
+
+Debianin osan levitysehdot eivät saa rajoittaa ketään myymästä tai antamasta kyseistä ohjelmistoa osana ohjelmistokokoelmaa, joka sisältää eri lähteistä saatuja ohjelmia. Nämä levitysehdot eivät saa vaatia myyjältä rojalteja tai muita maksuja.
+
+2~ 2. Lähdekoodi
+
+Ohjelman mukana tulee olla sen lähdekoodi, ja pitää olla sallittua levittää ohjelmaa lähdekielisenä kohdekielisen lisäksi.
+
+2~ 3. Johdannaisteokset
+
+Ohjelman levitysehtojen tulee sallia muutoksien ja johdannaisteosten tekeminen ja myös sallia näiden levittäminen samoin ehdoin kuin alkuperäisen ohjelman.
+
+2~ 4. Alkuperäisen lähdekoodin eheys
+
+Ohjelman levitysehdot saavat rajoittaa muutetun lähdekoodin levitystä _vain_, jos se sallii "muutostiedostojen" (patch files) levityksen lähdekoodin kanssa tarkoituksena muuttaa ohjelmaa käännösaikana. Levitysehtojen tulee erityisesti sallia muutetusta lähdekoodista tuotetun ohjelman levittäminen. Ne saavat vaatia, että johdannaisteoksien nimenä tai versionumerona käytetään jotain muuta kuin alkuperäisen ohjelman nimeä tai versionumeroa. (Tämä on kompromissi. Debian suosittelee kaikille ohjelmien tekijöille pidättäytymistä minkäänlaisten tiedostojen, lähde- tai kohdekielisten, muuttamisen kieltämisestä.)
+
+2~ 5. Ei ihmisten tai ihmisryhmien syrjintää
+
+Ohjelman levitysehdot eivät saa syrjiä ketään ihmistä tai mitään ihmisryhmää.
+
+2~ 6. Ei toiminnan alojen syrjintää
+
+Ohjelman levitysehdot eivät saa estää ketään käyttämästä ohjelmaa tietyllä alalla. Esimerkiksi ohjelman käyttöä yrityksessä ei saa rajoittaa, tai sen käyttöä geenitutkimuksessa.
+
+2~ 7. Levitysehtojen jatkuvuus
+
+Ohjelmaan liittyvien oikeuksien tulee koskea kaikkia, jotka ovat hankkineet ohjelmasta kappaleen ilman, että heidän tarvitsee hankkia erillinen lisenssi.
+
+2~ 8. Levityslupa ei saa olla vain Debianille
+
+Ohjelmaan liittyvät oikeudet eivät saa riippua ohjelman olemisesta osa Debiania. Jos ohjelma irrotetaan Debianista ja sitä käytetään tai levitetään ilman Debiania mutta muuten levitysehtojen mukaisesti, kaikilla osapuolilla tulee olla samat oikeudet, jotka annetaan Debian-järjestelmän yhteydessä.
+
+2~ 9. Levitysehdot eivät saa saastuttaa muita ohjelmia
+
+Ohjelman levitysehdot eivät saa asettaa rajoituksia muille ohjelmille, jotka levitetään kyseisen ohjelman kanssa. Ehdot eivät saa esimerkiksi vaatia, että muiden samalla levitysmedialla olevien ohjelmien tulee olla vapaita.
+
+2~ 10. Esimerkkilisenssejä
+
+"GPL", "BSD" ja "Artistic"-lisenssit ovat esimerkkejä lisensseistä, jotka ovat mielestämme "vapaita".
+
+Ean Schuessler ehdotti ajatusta tuoda julki "yhteiskunnallinen sopimuksemme vapaiden ohjelmistojen yhteisön kanssa". Bruce Perens kirjoitti tämän asiakirjan ensimmäisen luonnoksen ja paranteli sitä Debian-kehittäjien kommenttien perusteella kuukauden pituisen sähköpostikonferenssin aikana kesäkuussa 1997, ja joka sitten hyväksyttiin julkisesti esitettäväksi Debian-projektin linjaksi.
+
+Bruce Perens poisti myöhemmin Debian-spesifiset viittaukset Debianin vapaiden ohjelmien ohjeistosta luodakseen “Open Source -määritelmän”.
+
+Muut yhteisöt saavat luoda johdannaisia tästä asiakirjasta. Toivomme, että tunnustatte Debian-projektin roolin asiakirjan luomisessa, jos näin teette.
+
+Takaisin Debian-projektin kotisivulle.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~fr.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~fr.sst
new file mode 100644
index 00000000..deb46db2
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~fr.sst
@@ -0,0 +1,136 @@
+% SiSU 2.0
+
+@title: Le contrat social Debian
+ :subtitle: Debian Social Contract (v1.1)
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:policy:social contract;GNU/Linux:debian:social contract;language:French
+
+@date:
+ :created: 1997-07-05
+ :issued: 1997-07-05
+ :valid: 2004-04-26
+ :available: 2004-04-26
+ :modified: 2004-04-26
+ :publisher: 2004-04-26
+
+@language:
+ :document: French
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.da.html <br>« Debian » et le logo Debian sont des marques déposées appartenant à Software in the Public Interest, Inc.<br>En cas de litige, seule la version originale de cette page a valeur au regard de la loi http://www.debian.org/license.en.html.
+ :license: Ce matériel ne peut être distribué que conformément aux termes et conditions présentés dans la Licence de Publication Ouverte (Open Publication License), Draft v.1.0 ou suivantes. (Vous pouvez lire notre copie locale http://www.debian.org/opl, dont la version la plus récente est généralement disponible à http://www.opencontent.org/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/social_contract
+ {Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
+
+@make:
+ :breaks: new=C; break=1
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Le contrat social Debian
+
+1~pre [Prefix]-#
+
+Version 1.1 ratifiée le 26 avril 2004. Remplace la version 1.0 ratifiée le 5 juillet 1997.
+
+Le projet Debian, concepteur du système GNU/Linux Debian, a créé le contrat social de Debian. La partie consacrée aux principes du logiciel libre selon Debian (Debian Free Software Guidelines, ou DFSG), initialement conçue comme un ensemble de principes auxquels nous tenons fermement, a été adoptée par la communauté du logiciel libre comme base pour la définition de l'informatique libre (Open Source Definition).
+
+1~ « Contrat social » avec la communauté des logiciels libres
+
+2~ 1. Debian demeurera totalement libre.
+
+Nous fournissons les principes que nous utilisons pour déterminer si un travail est « libre » dans le document intitulé « Principes du logiciel libre selon Debian ». Nous promettons que le système Debian et tous ses composants seront libres selon ces principes. Nous aiderons les personnes qui créent et utilisent à la fois des travaux libres et non libres sur Debian. Nous ne rendrons pas le système dépendant d'un composant non libre.
+
+2~ 2. Nous donnerons nos travaux à la communauté des logiciels libres.
+
+Lorsque nous écrirons de nouveaux composants du système Debian, nous les publierons sous une licence compatible avec les principes du logiciel libre selon Debian. Nous ferons le meilleur système possible, afin que les travaux libres soient largement distribués et utilisés. Nous signalerons les corrections de bogues, les améliorations, les requêtes des utilisateurs, etc. aux auteurs des travaux originels inclus dans notre système.
+
+2~ 3. Nous ne cacherons pas les problèmes.
+
+Toute notre base de données sur les rapports de bogue sera consultable à tous moments par tous. Les rapports que les personnes remplissent en ligne seront immédiatement visibles par les autres.
+
+2~ 4. Nos priorités sont nos utilisateurs et les logiciels libres.
+
+Les besoins de nos utilisateurs et de la communauté des logiciels libres nous guideront. Nous placerons leurs intérêts en tête de nos priorités. Nous assumerons les besoins de nos utilisateurs dans de nombreux types d'environnements informatiques différents. Nous ne nous opposerons pas aux travaux non libres prévus pour fonctionner sur les systèmes Debian. Nous permettrons que d'autres créent des distributions contenant conjointement des logiciels Debian et d'autres travaux, et ceci sans réclamer aucune rétribution. Pour servir ces objectifs, nous fournirons un système intégré de composants de grande qualité sans restrictions légales qui empêcheraient ces types d'usage.
+
+2~ 5. Travaux non conformes à nos standards sur les logiciels libres.
+
+Nous reconnaissons que certains de nos utilisateurs demandent à pouvoir utiliser des travaux qui ne sont pas conformes aux principes du logiciel libre selon Debian. Pour ces travaux, nous avons créé des sections contrib (« contributions ») et non-free (« non libre ») dans notre archive. Les paquets dans ces sections ne font pas partie du système Debian, bien qu'ils aient été configurés afin d'être utilisés avec Debian. Nous encourageons les fabricants de CD à lire les licences des paquets en question afin de déterminer s'ils peuvent les distribuer dans leurs CD. Ainsi, bien que les travaux non libres ne fassent pas partie de Debian, nous assumons leur utilisation et fournissons une infrastructure (à l'image de notre système de suivi des bogues et de nos listes de diffusion) pour des paquets non libres.
+
+1~ Les principes du logiciel libre selon Debian
+
+2~ 1. Redistribution libre et gratuite.
+
+La licence d'un composant de Debian ne doit pas empêcher quiconque de vendre ou donner le logiciel sous forme de composant d'un ensemble (distribution) constitué de programmes provenant de différentes sources. La licence ne doit requérir ni redevance ni rétribution sur une telle vente.
+
+2~ 2. Code source.
+
+Le programme doit inclure le code source, et la diffusion sous forme de code source comme sous forme de programme compilé doit être autorisée.
+
+2~ 3. Applications dérivées.
+
+La licence doit permettre les modifications et les applications dérivées, et elle doit permettre à celles-ci d'être distribuées sous les mêmes termes que ceux de la licence du logiciel original.
+
+2~ 4. Intégrité du code source de l'auteur.
+
+La licence peut défendre de distribuer le code source modifié seulement si elle autorise la distribution avec le code source de fichiers correctifs destinés à modifier le programme au moment de la construction. La licence doit autoriser explicitement la distribution de logiciels créés à partir de code source modifié. Elle peut exiger que les applications dérivées portent un nom ou un numéro de version différent de ceux du logiciel original (c'est un compromis ; le groupe Debian encourage tous les auteurs à ne restreindre en aucune manière les modifications des fichiers, source ou binaire).
+
+2~ 5. Aucune discrimination de personne ou de groupe.
+
+La licence ne doit discriminer aucune personne ou groupe de personnes.
+
+2~ 6. Aucune discrimination de champ d'application.
+
+La licence ne doit pas défendre d'utiliser le logiciel dans un champ d'application particulier. Par exemple, elle ne doit pas défendre l'utilisation du logiciel dans une entreprise ou pour la recherche génétique.
+
+2~ 7. Distribution de licence.
+
+Les droits attachés au programme doivent s'appliquer à tous ceux à qui il est distribué sans obligation pour aucune de ces parties de se conformer à une autre licence.
+
+2~ 8. La licence ne doit pas être spécifique à Debian.
+
+Les droits attachés au programme ne doivent pas dépendre du fait qu'il fasse partie du système Debian. Si le programme est extrait de Debian et est utilisé et distribué sans Debian mais sous les termes de sa propre licence, toutes les parties auxquelles il est redistribué doivent jouir des même droits que ceux accordés avec le système Debian.
+
+2~ 9. La licence ne doit pas contaminer d'autres logiciels.
+
+La licence ne doit pas placer de restrictions sur d'autres logiciels distribués avec le logiciel licencié. Par exemple, la licence ne doit pas exiger que tous les autres programmes distribués sur le même support doivent être des logiciels libres.
+
+2~ 10. Exemples de licence.
+
+Les licences « GPL », « BSD » et « Artistic » sont des exemples de licences que nous considérons « libres ».
+
+L'idée de rédiger nos « principes du logiciel libre » fut suggérée par Ean Schuessler. Bruce Perens écrivit la première ébauche de ce document et le perfectionna d'après les commentaires des développeurs de Debian recueillis à l'occasion d'une conférence par courriels qui s'est déroulé pendant tout le mois de juin 1997. Il fut ensuite accepté comme faisant partie intégrante de la charte du projet Debian.
+
+Plus tard, Bruce Perens retira toute référence au projet Debian des DFSG pour en faire la « Définition de l'Open Source ».
+
+D'autres organisations peuvent utiliser ce document. Si vous le faites, veuillez faire référence au projet Debian.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~it.sst b/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~it.sst
new file mode 100644
index 00000000..a4a4f5c2
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v2/debian_social_contract_v1.1~it.sst
@@ -0,0 +1,128 @@
+% SiSU 2.0
+
+@title: Contrato social de Debian
+ :subtitle: Debian Social Contract (v1.1)
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:policy:social contract;GNU/Linux:debian:social contract;language:Italian
+
+@date:
+ :published: 2004-04-26
+ :created: 1997-07-05
+ :issued: 1997-07-05
+ :valid: 2004-04-26
+ :available: 2004-04-26
+ :modified: 2004-04-26
+
+@language:
+ :document: Italian
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.it.html <br>“Debian” e il Logo Debian http://www.debian.org/logos/ sono trademark di Software in the Public Interest, Inc.<br>N.d.T.: Questa è una traduzione della licenza originale in inglese. In tutti in casi in cui il significato della traduzione differisca da quello dell’originale, la versione corretta è da considerarsi quella originale http://www.debian.org/license.en.html.
+ :license: Questo materiale può essere distribuito solo ai termini e sotto le consizioni poste nel “Open Publication License”, Bozza v1.0 o successiva (si può leggere la nostra copia http://www.debian.org/opl o l’ultima versione normalmente disponibile presso http://www.opencontent.org/openpub/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/social_contract
+ {Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
+
+@make:
+ :breaks: new=:C; break=1
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Il Contratto Sociale Debian
+
+1~pre [Prefix]-#
+
+La versione 1.1 approvata il 26 aprile 2004 che sostituisce la versione 1.0 approvata il 5 luglio 1997.
+
+Debian, i produttori del sistema Debian GNU/Linux, ha creato il Contratto Sociale Debian (Debian Social Contract). Le Linee Guida Debian per il Software Libero (Debian Free Software Guidelines - DFSG) che sono parte del contratto, inizialmente pensate come un insieme di punti che noi tutti sottoscriviamo, sono state adottate dalla comunità del software libero come base per l'Open Source Definition.
+
+1~ Contratto Sociale con la Comunità Free Software
+
+2~ 1. Debian rimarrà libera al 100%
+
+Forniamo le linee guida che usiamo per determinare se un'opera sia "libera" nel documento intitolato "The Debian Free Software Guidelines". Promettiamo che il sistema Debian e tutte le sue componenti rimarranno liberi in accordo con le citate linee guida. Supporteremo le persone che creino o usino in Debian opere sia libere che non libere. Non renderemo mai il sistema dipendente da un componente non libero.
+
+2~ 2. Renderemo alla Comunità Free Software
+
+Quando scriviamo nuovi componenti del sistema Debian, li rilasceremo con una licenza che rispetti le Debian Free Software Guidelines. Realizzeremo il sistema migliore che potremo, cosicché le opere libere siano usate e distribuite il più possibile. Comunicheremo cose come bug fix, migliorie e richieste degli utenti agli autori "upstream" delle opere incluse nel nostro sistema.
+
+2~ 3. Non nasconderemo i problemi
+
+Manterremo sempre il nostro intero bug report database aperto alla pubblica lettura. I rapporti che le persone invieranno online saranno prontamente resi visibili a tutti.
+
+2~ 4. Le nostre priorità sono gli utenti ed il software libero
+
+Ci faremo guidare dai bisogni dei nostri utenti e della comunità del software libero. Metteremo al primo posto i loro interessi. Supporteremo le necessità dei nostri utenti di operare in molti diversi tipi di ambienti di calcolo. Non ci opporremo alle opere non libere che siano state pensate per l'uso in sistemi Debian e non richiederemo compensi a chi crea o usa queste opere. Permetteremo ad altri di creare distribuzioni contenenti sia il sistema Debian che altre opere, senza richiedere compensi. Per raggiungere questi scopi, forniremo un sistema integrato di materiali di alta qualità senza alcuna restrizione legale che limiti qualsiasi uso del sistema.
+
+2~ 5. Opere che non rispettano i nostri standard free software
+
+Ci rendiamo conto che alcuni dei nostri utenti richiedono di usare opere non conformi alle Debian Free Software Guidelines. Abbiamo creato le aree "contrib" e "non-free" nel nostro archivi per queste opere. I pacchetti in queste aree non fanno parte del sistema Debian, sebbene siano stati configurati per l'uso con Debian. Invitiamo i realizzatori di CD a leggere le licenze dei pacchetti in queste aree per determinare se possono distribuire i pacchetti sui loro CD. Inoltre, anche se le opere non libere non fanno parte di Debian, supporteremo il loro uso e forniremo infrastrutture per i pacchetti non liberi (come il nostro bug tracking system e le mailing list).
+
+1~ Le Linee Guida Debian per il Software Libero (Debian Free Software Guidelines - DFSG)
+
+2~ 1. Libera ridistribuzione
+
+La licenza di un componente Debian non può porre restrizioni a nessuno per la vendita o la cessione del software come componente di una distribuzione software aggregata di programmi proveniente da fonti diverse. La licenza non può richiedere royalty o altri pagamenti per la vendita.
+
+2~ 2. Codice sorgente
+
+Il programma deve includere il codice sorgente e deve permettere la distribuzione sia come codice sorgente che in forma compilata.
+
+2~ 3. Lavori derivati
+
+La licenza deve permettere modifiche e lavori derivati e deve permettere la loro distribuzione con i medesimi termini della licenza del software originale.
+
+2~ 4. Integrità del codice sorgente dell'autore
+
+La licenza può porre restrizioni sulla distribuzione di codice sorgente modificato _solo_ se permette la distribuzione di "file patch" insieme al codice sorgente con lo scopo di modificare il programma durante la compilazione. La licenza deve esplicitamente permettere la distribuzione di software compilato con codice sorgente modificato. La licenza può richiedere che i lavori derivati abbiano un nome o un numero di versione diversi da quelli del software originali. (Questo è un compromesso. Il gruppo Debian invita tutti gli autori a non impedire che file, sorgenti o binari possano essere modificati.)
+
+2~ 5. Nessuna discriminazione di persone o gruppi
+
+La licenza non può discriminare nessuna persona o gruppo di persone.
+
+2~ 6. Nessuna discriminazione nei campi di impiego
+
+La licenza non può porre restrizioni all'utilizzo del programma in uno specifico campo di impiego. Per esempio, non può porre restrizioni all'uso commerciale o nella ricerca genetica.
+
+2~ 7. Distribuzione della licenza
+
+I diritti applicati al programma devono essere applicabili a chiunque riceva il programma senza il bisogno di utilizzare licenze addizionali di terze parti.
+
+2~ 8. La licenza non può essere specifica per Debian
+
+I diritti applicati al programma non possono dipendere dal fatto che esso sia parte di un sistema Debian. Se il programma è estratto da Debian e usato o distribuito senza Debian ma ottemperando ai termini della licenza, tutte le parti alle quali il programma è ridistribuito dovrebbero avere gli stessi diritti di coloro che lo ricevono con il sistema Debian.
+
+2~ 9. La licenza non deve contaminare altro software
+
+La licenza non può porre restrizioni ad altro software che sia distribuito insieme al software concesso in licenza. Per esempio, la licenza non può richiedere che tutti gli altri programmi distribuiti con lo stesso supporto debbano essere software libero.
+
+2~ 10. Esempi di licenze
+
+Le licenze "GPL", "BSD" e "Artistic" sono esempi di licenze che consideriamo "libere".
+
+I concetti enunciati nel nostro "contratto sociale con la comunità del software libero" furono proposti da Ean Schuessler. Questo documento fu abbozzato da Bruce Perens, rifinito da altri sviluppatori Debian durante una conferenza via posta elettronica durata un mese (Giugno 1997) ed infine approvata come pubblica linea di condotta del Progetto Debian.
+
+Bruce Perens in seguito ha rimosso i riferimenti specifici a Debian dalle Linee Guida Debian per il Free Software per creare “L'Open Source Definition”.
+
+Altre organizzazioni possono derivare da questo documento. Per favore, se lo si fa, se ne dia credito al progetto Debian.
+
+Ritorna alla pagina principale del Progetto Debian.
+
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/_sisu/skin/doc/skin_debian.rb b/debian/data/doc/sisu/markup-samples/samples/v3/_sisu/skin/doc/skin_debian.rb
new file mode 100644
index 00000000..46d29e6c
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/_sisu/skin/doc/skin_debian.rb
@@ -0,0 +1,83 @@
+=begin
+ * Name: SiSU information Structuring Universe - Serialised information, Structured Units
+ * Author: Ralph@Amissah.com
+ * http://www.jus.uio.no/sisu
+ * http://www.jus.uio.no/sisu/SiSU/download
+ * Description: Document skin for SiSU descriptive pages, ...
+ * License: Same as SiSU see http://www.jus.uio.no/sisu
+ * Notes: Site default appearance variables set in defaults.rb
+ Generic site wide modifications set here scribe_skin.rb, and this file required by other "scribes" instead of defaults.rb
+=end
+module SiSU_Viz
+ require "#{SiSU_lib}/defaults" #<url:zxy_defaults.rb>
+ class Skin
+ #% path
+ def path_root
+ './sisu/' # the only parameter that cannot be changed here
+ end
+ def path_rel
+ '../'
+ end
+ #% url
+ def url_root_http
+ 'http://www.jus.uio.no/sisu'
+ end
+ def url_home
+ 'http://www.debian.org/'
+ end
+ def url_site # used in pdf header
+ 'http://www.debian.org'
+ end
+ def url_txt # text to go with url usually stripped url
+ 'www.debian.org'
+ end
+ def url_home_url
+ '../index.html'
+ end
+ #% color
+ def color_band1
+ '"#ffffff"'
+ end
+ def color_band2
+ '"#ffffff"'
+ end
+ #% txt
+ def txt_hp
+ '&nbsp;Debian'
+ end
+ def txt_home
+ 'Debian'
+ end
+ #% icon
+ def icon_home_button
+ 'debian_home.png'
+ end
+ def icon_home_banner
+ home_button
+ end
+ #% banner
+ def banner_home_button
+ %{<table summary="home button" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/">#{png_home}</a></td></tr></table>\n}
+ end
+ def banner_home_and_index_buttons
+ %{<table><tr><td width="20%"><table summary="home and index buttons" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}</td><td width="60%"><center><center><table summary="buttons" border="1" cellpadding="3" cellspacing="0"><tr><td align="center" bgcolor="#ffffff"><font face="arial" size="2"><a href="toc" target="_top">&nbsp;This&nbsp;text&nbsp;sub-&nbsp;<br />&nbsp;Table&nbsp;of&nbsp;Contents&nbsp;</a></font>#{table_close}</center></center></td><td width="20%">&nbsp;#{table_close}}
+ end
+ def banner_band
+ %{<table summary="band" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}}
+ end
+ end
+ class TeX
+ def header_center
+ "\\chead{\\href{#{@vz.url_site}/}{www.debian.org}}"
+ end
+ def home_url
+ "\\href{#{@vz.url_site}/}{www.debian.org}"
+ end
+ def home
+ "\\href{#{@vz.url_site}/}{Debian}"
+ end
+ def owner_chapter
+ "Document owner details"
+ end
+ end
+end
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/da/debian_constitution_v1.2.sst b/debian/data/doc/sisu/markup-samples/samples/v3/da/debian_constitution_v1.2.sst
new file mode 100644
index 00000000..a8a2a274
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/da/debian_constitution_v1.2.sst
@@ -0,0 +1,501 @@
+% SiSU 2.0
+
+@title: Debians vedtægter
+ :subtitle: Debian-projektets vedtægter (v1.2) [This Document has been Superseded by v1.3]
+
+@creator:
+ :author: Debian Project
+
+@date:
+ :published: 2003-10-29
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2003-10-29
+ :available: 2003-10-29
+ :modified: 2003-10-29
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.da.html <br>"Debian" og Debians logo http://www.debian.org/logos/ er varemærker tilhørende Software in the Public Interest, Inc.<br>Dette er en oversættelse af det originale engelsksprogede dokument http://www.debian.org/license.en.html.
+ :license: Dette materiale må kun distribueres i henhold til vilkårene beskrevet i Open Publication License, udkast (draft) v1.0 eller senere (du kan læse vores lokale kopi http://www.debian.org/opl, den seneste version er normalt tilgængelig på http://www.opencontent.org/openpub/ ).
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution;language:Danish
+
+@language:
+ :document: Danish
+ :original: English
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+:A~ Debians vedtægter
+
+:B~ Debian-projektets vedtægter (v1.2) [This Document has been Superseded by v1.3]
+
+1~pre [Prefix]-#
+
+Version 1.2 blev godkendt den 29. oktober 2003. Erstatter version 1.1 som blev godkendt den 21. juni 2003, der erstattede version 1.0 som blev godkendt den 2. december 1998.
+
+1~1 §1. Introduktion
+
+Debian-projektet er en sammenslutning af personer, som har det fælles mål at udvikle et frit tilgængeligt styresystem.
+
+Dette dokument beskriver organisationsstrukturen for formelle beslutninger i projektet. Det beskriver ikke projektets mål eller hvordan vi opfylder disse, og indeholder ingen retningslinier, bortset fra de retningslinier som direkte vedrører beslutningsprosessen.
+
+1~2 §2. Beslutningsdygtige organer og -personer
+
+Enhver beslutning i projektet er omfattet af en eller flere af følgende:
+
+# Udviklerne, via en fælles resolution eller et valg;
+
+# Projektlederen;
+
+# Den tekniske komité og/eller dennes formand;
+
+# Den individuelle udvikler som arbejder med en bestemt opgave;
+
+# Delegater udnævnt af projektlederen til at varetage særlige opgaver;
+
+# Projektsekretæren.
+
+Resten af dette dokument vil primært beskrive disse organers fuldmagter, deres sammensætning og udnævnelse, og procedurer for vedtagelser. En persons eller et organs fuldmagt kan i visse tilfælde blive genstand for gennemsyn af andre; i så fald vil det fremgå af afsnittet om det organ, der står for dette. I listen ovenfor er hver person eller hvert organ stort set anført før de personer eller organer de kan (hjælpe til med at) udnævne, og hvis beslutninger de kan ophæve - men ikke alle, der er anført tidligere, kan ophæve beslutninger fortaget af alle som er anført senere.
+
+2~2.1 §2.1. Generelle regler
+
+# Intet i disse vedtægter forpligter nogen til at arbejde for projeket. En person, der ikke vil udføre en opgave, som er blevet uddelegeret eller pålagt vedkommende, behøver at gøre det. Derimod kan man ikke aktivt modarbejde regler eller beslutninger, som er foretaget korrekt i henhold til reglerne.
+
+# En person kan bestride flere hverv, bortset fra at projektlederen, projektsekretæren og formanden for den tekniske komité skal være forskellige personer, og lederen kan ikke udnæve sig selv, som sin egen delegat.
+
+# En person kan til enhver tid forlade projektet eller fratræde et særskilt hverv vedkommende har, ved offentligt at erklære dette.
+
+1~3 §3. Individuelle udviklere
+
+2~3.1 §3.1. Fuldmagt
+
+En individuel udvikler kan
+
+# tage tekniske og ikke-tekniske beslutninger med hensyn til sit eget arbejde;
+
+# foreslå og støtte udkast til generelle resolutioner;
+
+# foreslå sig selv som kandidat til projektleder i valg;
+
+# stemme på generelle resolutioner og i ledervalg.
+
+2~3.2 §3.2. Sammensætning og udnævnelse
+
+# Udviklere er frivillige som er enige om at fremme projektets mål for så vidt som de deltager i det, og som vedligeholder pakke(r) for projektet eller gør andet arbejde, som projeketlederens delegater anser for værdifuldt.
+
+# Projektlederens delegater kan vælge ikke at optage nye udviklere, eller at ekskludere nuværende udviklere. Hvis udviklerne mener at delegaterne misbruger deres autoritet, kan de selvfølgelig ophæve en beslutning via en generel resolution - se §4.1(3) og §4.2.
+
+2~3.3 §3.3. Fremgangsmåder
+
+Udviklerne kan foretage disse beslutninger efter eget skøn.
+
+1~4 §4. Udviklerne via generel resolution eller et valg
+
+2~4.1 §4.1. Fuldmagt
+
+Udviklerne kan sammen:
+
+# Udnævne eller afsætte projektlederen.
+
+# Ændre disse vedtægter med et 3:1-flertal.
+
+# Ophæve enhver beslutning taget af projektlederen eller en delegat.
+
+# Ophæve enhver beslutning taget af den tekniske komité, såfremt de er enige med et 2:1-flertal.
+
+# Udgive, erstatte og tilbagetrække ikke-tekniske retningslinier og erklæringer.
+
+Dette inkluderer dokumenter som forklarer projektmål, dets forhold til andre organer indenfor fri software, samt ikke-tekniske vejledninger som de fri software-licensbetingelser, som Debians programmel skal leve op til.
+
+Det kan også være stillingtagen til aktuelle emner.
+
+_# Et grundlæggende dokument er et dokument eller en bekendtgørelse, der betragtes som kritisk for projekts arbejde og formål.
+
+_# De grundlæggende dokumenter er det arbejde som er udmundet i Debian sociale kontrake og Debians retningslinier for fri software.
+
+_# Et grundlæggende dokument kræver et 3:1-flertal for dets erstatning. Nye grundlæggende dokumenter udgives og eksisterende dokumenter trækkes tilbage ved at føje til listen over grundlæggende dokumenter i disse vedtægter.
+
+# Træffe beslutninger sammen med projektlederen og SPI om forvaltede ejendele til formål der har relation til Debian. (Se §9.1).
+
+2~4.1 §4.2. Fremgangsmåde
+
+# Udviklerne følger de generelle resolutionsprocedurer beskrevet nedenfor. En resolution eller ændring betragtes som introduceret, hvis den er foreslået af en hvilken som helst udvikler og mindst K andre udviklere støtter den, eller hvis den er foreslået af projektlederen eller den tekniske komité.
+
+# Udsættelse af en resolution foretaget af projektlederen eller dennes delegater:
+
+_# Hvis projektlederen, dennes delegater eller den tekniske komité har truffet en beslutning, kan udviklerne ophæve denne ved at vedtage en resolution derom, se §4.1(3).
+
+_# Hvis en sådan resolution støttes af mindst 2K udviklere eller hvis den er foreslået af den tekniske komité, vil resolutionen omgående tilsidesætte beslutningen (såfremt resolutionen selv siger dette).
+
+_# Hvis den oprindelige beslutning var at ændre en diskussionsperiode eller en stemmeperiode, eller hvis resolutionens formål er at ophæve en beslutning foretaget af den tekniske komité, behøver kun K udviklere at støtte resolutionen, for omgående at kunne tilsidesætte beslutningen.
+
+_# Hvis beslutningen er tilsidesat, holdes omgående en afstemning for at afgøre om beslutningen skal opretholdes indtil en fuldstændig afstemning om beslutningen kan holdes, eller om udførslen af den oprindelige beslutning skal udsættes indtil da. Der findes ikke et beslutningsdygtigt antal stemmer i denne omgående, proceduriske afstemning.
+
+_# Hvis projektlederen (eller dennes delegater) trækker den oprindelige beslutning tilbage, bliver det uaktuelt at holde afstemningen og den vil ikke blive afholdt.
+
+# Stemmer indsamles af projektsekretæren. Stemmerne og afstemningsresultatet offentliggøres ikke i stemmeperioden; efter afstemningen opremser projektsekretæren alle de afgivne stemmer, Afstemningsperioden er to uger, men projektlederen kan tilføje eller fjerne op til en uge.
+
+# Minimumstiden for diskussion er to uger, men projektlederen kan tilføje eller fjerne op til en uge. Projektlederen har den afgørende stemme. Det beslutningsdygtige antals stemmer er 3Q.
+
+# Forslag, støtte, ændringer, stemmeopråb og andre formelle handlinger foregår via erklæringer på en offentlig tilgængelig elektronisk postliste udvalgt af projektlederens delegat(er); alle udviklere har skriveadgang til den.
+
+# Stemmer afgives via e-mail på en måde der bestemmes af sekretæren. Sekretæren bestemmer for hver afstemning hvorvidt vælgerne kan ændre deres stemmer.
+
+# Q er halvdelen af kvadratroden af antallet af udviklere. K er den mindste af Q og 5. Q og K behøver ikke at være heltal, og de afrundes ikke.
+
+1~5 §5. Projektlederen
+
+2~5.1 §5.1. Fuldmagt
+
+Projektlederen kan:
+
+# Udnævne delegater eller uddelegere beslutninger til den tekniske komité.
+
+Lederen kan beskrive en opgave med løbende ansvar eller en særskilt beslutning. I begge tilfælde overføres denne til en anden udvikler eller til den tekniske komité.
+
+Efter en særskilt beslutning er blevet uddelegeret og afgjort, kan projektlederen ikke trække uddelegeringen tilbage. derimod kan en løbende uddelegerning til en bestemt opgave trækkes tilbage.
+
+# Give hjemmel til andre udviklere.
+
+Projektlederen kan udgive støtteerklæringer til andres synspunkter eller andre projektmedlemmer, uden at være blevet bedt om det. Disse støtteerklæringer er gyldige, hvis, og kun hvis, lederen ville have haft fuldmagt til at træffe den foreliggende beslutning.
+
+# Foretage beslutninger som kræver omgående handling.
+
+Dette gælder ikke beslutninger som gradvist er blevet påtrængende på grund af manglende, relevant handling, med mindre der er en fastsat frist.
+
+# Foretage beslutninger som ingen andre har ansvaret for.
+
+# Fremstille udkast til generelle resolutioner og ændringsforslag.
+
+# Sammen med den tekniske komité udpege nye medlemmer til komitéen. (Se §6.2.)
+
+# Afgive en afgørende stemme i udviklernes afstemninger.
+
+Projektlederen har også almindelig stemmeret i sådanne afstemninger.
+
+# Ændre diskussionsperioden for udviklernes afstemninger (som beskrevet ovenfor).
+
+# Lede diskussioner blandt udviklerne.
+
+Projektlederen bør prøve at deltage i diskussioner blandt udviklerne på en hjælpsom måde, som søger at bringe diskussionen på rette kurs mod sagens kerne. Projektlederen bør ikke bruge lederpositionen til at fremme sine egne personlige synspunkter.
+
+# Tage beslutninger sammen med SPI, der vedrører ejendele som administreres til formål der vedrører Debian. (Se §9.1.)
+
+2~5.2 §5.2. Udnævnelse
+
+# Projektlederen vælges af udviklerne.
+
+# Valget begynder ni uger før lederpositionen bliver ledig eller (hvis det ikke allerede er for sent) omgående.
+
+# I de følgende tre uger kan enhver udvikler nominere sig selv som projektlederkandidat.
+
+# I de efterfølgende tre uger kan der ikke nomineres flere kandidater; kandiaterne bør anvende dette tidsrum til deres valgkamp (for at gøre opmærksom på sig selv og sine synspunkter). Hvis der ikke er nogen kandidater efter nomineringsperioden er slut, bliver perioden udvidet med yderligere tre uger, om nødvendigt gentagne gange.
+
+# De næste tre uger er valgperioden, hvori udviklerene kan stemme. Afstemningen i ledervalg er hemmelig, selv efter afstemningen er afsluttet.
+
+# Valget vil være mellem de kandidater, der har nomineret sig selv og som ikke har trukket sig tilbage, samt Ingen af de nævnte ("None of the Above"). Hvis Ingen af de nævnte vinder valget, bliver denne procedure gentaget, om nødvendigt mange gange.
+
+# Beslutningen træffes ved hjælp af den metode, som er beskrevet i afsnit §A.6 i de generelle resolutionsprocedurer. Det beslutningsdygtige antal er det samme, som ved en generel resolution (§4.2), og standardvalget er Ingen af de nævnte.
+
+# Projektlederen vælges for et år ad gangen.
+
+2~5.3 §5.3. Fremgangsmåde
+
+Projektlederen bør prøve at træffe beslutninger som er i tråd med konsensus blandt udviklerne.
+
+Hvor det er praktisk bør projektlederen på en uformel måde bede om udviklernes synspunkter.
+
+Projektlederen bør undgå at lægge for megen vægt på sine egne synspunkter, når der træffes beslutninger i vedkommendes egenskab af leder.
+
+1~6 §6. Teknisk komité
+
+2~6.1 §6.1. Fuldmagt
+
+Den tekniske komité kan:
+
+# Træffe beslutninger om tekniske retningslinier.
+
+Deriblandt også indholdet af de tekniske retningslinier, udviklernes håndbogsmateriale, pakkeeksempler og hvordan ikke-eksperimentelle pakkeopbygningsværktøjer skal fungere. (I hvert tilfælde træffer den almindelige pakkevedligeholder af programmellet eller dokumentationen, de første beslutninger; se §6.3(5).)
+
+# Afgøre tekniske spørgsmål hvor udviklernes ansvarsområder overlapper.
+
+I tilfælde hvor udviklere skal implementere kompatible tekniske retningslinier eller holdninger (for eksempel hvis de ikke er enige om prioriteringerne ved uforenlige pakker, eller om ejerskab af et kommandonavn, eller om hvilken pakke der er ansvarlig for en fejl som begge pakkevedligeholdere er enige om er en fejl, eller om hvem der bør være vedligeholder af en pakke), kan den tekniske komité afgøre sagen.
+
+# Træffe en beslutning når den bliver bedt om at gøre dette.
+
+Enhver person og ethvert organ kan uddelegere en af sine egne beslutninger til den tekniske komité eller bede om råd fra den.
+
+# Tilsidesætte en udviklers beslutning (kræver et 3:1-flertal)
+
+Den tekniske komité kan bede en udvikler om at benytte en bestemt fremgangsmåde, selvom udvikleren ikke ønsker det; dette kræver et 3:1-flertal. For eksempel kan komitéen komme frem til at en klage fremsat i en fejlrapport er gyldig og at indsenderens foreslåede løsning bør iværksættes.
+
+# Give råd.
+
+Den tekniske komité kan give formelle erklæringer om sit syn på enhvert emne. Individuelle medlemmer kan selvfølgelig give uformelle erklæringer om deres synspunkter og om komitéens sandsynlige synspunkter.
+
+# Sammen med projektlederen udnævne nye medlemmer til sig selv eller fjerne nuværende medlemmer. (Se §6.2.)
+
+# Udnævne formanden for den tekniske komité.
+
+Komitéen vælger formand blandt sine medlemmer. Medlemmerne af komitéen nomineres automatisk; valget starter en uge før stillingen bliver ledig (eller omgående, hvis det allerede er for sent). Medlemmerne kan stemme via offentlig tilkendegivelse for hvilket som helst komitémedlem, også sig selv. Der er intet standardvalg. Valget afsluttes når alle medlemmerne har stemt eller stemmeperioden er afsluttet. Resultatet afgøres ved hjælp af den metode, som er angivet i §A.6 i de generelle resolutionsprocedurer.
+
+# Formanden kan vikariere for lederen, sammen med sekretæren
+
+Som beskrevet i §7.1(2), kan formanden for den tekniske komité og projektsekretæren i fællesskab vikariere for lederen, hvis der ikke er en leder.
+
+2~6.2 §6.2. Sammensætning
+
+# Den tekniske komité består af op til otte udviklere og bør normalt have mindst fire medlemmer.
+
+# Hvis det er mindre end otte medlemmer, kan den tekniske komité anbefale ny(e) medlem(mer) til projektlederen, som (på egen hånd) kan vælge at udnævne dem eller ej.
+
+# Hvis der er fem eller færre medlemmer, kan den tekniske komité udnævne ny(e) medlem(mer) indtil antallet af medlemmer når seks.
+
+# Når der har været fem eller færre medlemmer i mindst en uge, kan projektlederen udnævne nye medlem(mer) indtil antallet af medlemmer når seks, med mindst en uges mellemrum for hver udnævnelse.
+
+# Hvis den tekniske komité og projektlederen er enige kan de fjerne eller erstatte et nuværende medlem af den tekniske komité.
+
+2~6.3 §6.3. Fremgangsmåde
+
+# Den tekniske komité anvender den generelle resolutionsprocedure.
+
+Et udkast til en resolution eller ændring kan framsættes af ethvert medlem af den tekniske komité. Det er ingen minimumstid for diskussion; valgperioden varer i op til en uge eller indtil der ikke længere kan være nogen tvivl om resultatet. Medlemmerne kan ændre deres stemmer. Det beslutningsdygtige antal er to.
+
+# Detaljerede afstemningoplysninger
+
+Formanden har den afgørende stemme. Når den tekniske komité stemmer for at afgøre, om de skal tilsidesætte en afgørelse taget af en udvikler, der også er et medlem af komitéen, kan dette medlem ikke stemme (med mindre det er formanden, som i dette tilfælde kun kan benytte sin afgørende stemmeret).
+
+# Offentlig diskussion og afgørelser
+
+Diskussioner, udkast til resolutioner og ændringer og komitemedlemmernes stemmer offentliggøres på den tekniske komités offentlige diskussionsliste. Der er ikke en særskilt sekretær for komitéen.
+
+# Fortrolighed ved udnævnelser
+
+Den tekniske komité kan holde fortrolige diskussioner via privat e-mail eller en privat postliste, eller på andre måder diskutere udnævnelser til komitéen. Derimod skal stemmerne ved udnævnelser offentliggøres.
+
+# Ikke et detaljeret udviklingsarbejde
+
+Den tekniske komité giver sig ikke i kast med fremstilling af nye forslag og retningslinier. Sådant udviklingsarbejde bør foretages privat af personer eller grupper, og diskuteres i almindelige tekniske og udviklingsfora.
+
+Den tekniske komité begrænser sig selv til at vælge blandt, eller vælge et kompromis mellem, løsninger og afgørelser, der er blevet foreslået og er blevet drøftet tilpas meget andre steder.
+
+Medlemmer af den tekniske komité kan selvfølgelig deltage på egne vegne i alle aspekter af udviklings- og retningsliniearbejde.
+
+# Den teknisk komité træffer kun afgørelser som en sidste udvej
+
+Den tekniske komité træffer ikke en teknisk afgørelse før der uden held har været gjort forsøg på at løse problemet ved konsensus, med mindre den er blevet bedt om at træffe en afgørelse af personen eller organet, der normalt ville have haft ansvar for at gøre dette.
+
+1~7 §7. Projektsekretæren
+
+2~7.1 §7.1. Fuldmagt
+
+Sekretæren:
+
+# Indsamler stemmer fra udviklerne, finder ud af hvor mange udviklere der er og hvem de er, når dette kræves af vedtægterne.
+
+# Kan vikariere for lederen, i fællesskab med formanden for den tekniske komité.
+
+Hvis der ikke er en projektleder, kan formanden for den tekniske komité og projektsekretæren træffe afgørelser ved enighed, hvis de mener at det er vigtigt at gøre dette.
+
+# Dømmer i stridigheder om tolkning af vedtægterne.
+
+# Kan uddelegere dele af eller hele sin fuldmagt til andre, eller til enhver tid trække en sådan uddelegering tilbage.
+
+2~7.2 §7.2. Udnævnelse
+
+Projektsekretæren udnævnes af projektlederen og den forrige projektsekretær.
+
+Hvis projektlederen og den forrige projektsekretær ikke kan blive enige om en ny udnævnelse, skal de bede SPI's bestyrelse (se §9.1) om at udnævne en ny sekretær.
+
+Hvis der ikke er en projektsekretær eller den forrige sekretær ikke kan træffes og ikke har uddelegeret sin fuldmagt til en sådan beslutning, kan beslutningen træffes eller uddelegeres af formanden for den tekniske komité, som fungerende sekretær.
+
+Projektsekretæren er valgt for et år ad gangen, hvorefter en ny (gen)udnævnelse er nødvendig.
+
+2~7.3 §7.3. Fremgangsmåde
+
+Projektsekretæren bør træffe afgørelser som er retfærdige og rimelige, og helst i overensstemmelse med konsensus blandt udviklerne.
+
+Når projektsekretæren og formanden for den tekniske komité i fællesskab vikarierer for en projektleder som ikke kan træffes, bør de kun træffe beslutninger som er helt nødvendige og kun når det er i overensstemmelse med konsensus blandt udviklerne.
+
+1~8 §8. Projektlederens delegater
+
+2~8.1 §8.1. Fuldmagt
+
+Projektlederens delegater:
+
+# har fået uddelegeret en fuldmagt fra projektlederen;
+
+# kan træffe visse afgørelser som lederen ikke kan tage på egen hånd, deriblandt optagelse eller afvisning af udviklere, eller udnævne folk der ikke håndterer pakker, som udviklere. Dette er for at undgå en magtkoncentration hos projektlederen, særligt med hensyn til udviklermedlemskab.
+
+2~8.2 §8.2. Udnævnelse
+
+Delegaterne udnævnes af projektlederen, og lederen kan udskifte dem, som han finder det passende. Projektlederen kan ikke gøre udnævnelse betinget af at delegaten træffer bestemte afgørelser, lederen kan heller ikke ophævne en beslutning truffet af en delegat.
+
+2~8.3 §8.3. Fremgangsmåde
+
+Delegater kan til enhver tid træffe afgørelser, men bør prøve at opnå gode tekniske vilkår og/eller følge konsensus.
+
+1~9 §9. Software in the Public Interest ("Software i offentlighedens interesse")
+
+SPI og Debian er adskilte organisationer, der har nogle fælles mål. Debian er taknemlig for det juridiske støtteapparat, som SPI tilbyder. Debians udviklere er pt. medlemmer af SPI i kraft af deres hverv som udviklere.
+
+2~9.1 §9.1. Fuldmagt
+
+# SPI har ingen fuldmagt hvad angår Debians tekniske eller ikke-tekniske beslutninger, bortset fra at ingen beslutninger foretaget af Debian som vedrører ejendele der administreres af SPI, kan kræve at SPI handler udenfor sin juridiske fuldmagt, og Debians vedtægter kan af og til gøre SPI til en afgørende myndighed, som en sidste udvej.
+
+# Debian har ingen bestemmende kontrol over SPI, bortset fra anvendelse af visse ejendele som beskrevet nedenfor, selvom Debians udviklere kan få fuldmagt indenfor SPI efter SPI's regler.
+
+# Debians udviklere er ikke repræsentanter for, eller ansat af, SPI, eller af personer med fuldmagt i Debian-projektet. En person der handler som udvikler, gør dette som et individ på egne vegne.
+
+2~9.2 §9.2. Administration af ejendele til formål som vedrører Debian
+
+Da Debian ikke har fuldmagt til at forvalte penge eller ejendele, skal donationer til Debian-projektet gives til SPI, som håndterer den slags.
+
+SPI har påtaget sig følgende:
+
+# SPI vil forvalte penge, varemærker, andre konkrete ejendele og forretninger til formål som vedrører Debian.
+
+# Sådanne ejendele vil der blive holdt særskilt regnskab for og blive indsat i en fond med det formål, udvalgt af Debian og SPI i henhold til denne paragraf.
+
+# SPI vil ikke afhænde eller anvende ejendele, de administrerer for Debian, uden samtykke med Debian, som kan gives af projektlederen eller via en generel resolution blandt udviklerne.
+
+# SPI vil overveje anvendelse og/eller afhændelse af ejendele de administrerer for Debian, når de bliver bedt om det af projektlederen.
+
+# SPI vil anvende eller afhænde ejendele som administreres for Debian når de bliver bedt om at gøre dette, via en generel resolution blandt udviklerne, såfremt dette er foreneligt med SPI's juridiske fuldmagt.
+
+# SPI vil via elektronisk post til en af Debian-projektets postlister, gør opmærksom på når ejendele, der administreres for Debian, anvendes eller afhændes.
+
+1~a A. Generel resolutionsprocedure
+
+Disse regler gælder fælles beslutninger truffet af komitéer og ved afstemninger, som beskrevet ovenfor.
+
+2~a1 A.1. Forslag
+
+Den formelle procedure begynder når et udkast til en beslutning er foreslået og støttet, som krævet.
+
+2~a1a A.1. Diskussion og ændring
+
+# Efter forslaget er fremsat, kan resolutionen diskuteres. Ændringsforslag kan gøres formelle ved at fremsætte dem og skaffe støtter jævnfør kravene for nye resolutioner, eller direkte af forslagsstilleren af det oprindelige forslag.
+
+# Et formelt ændringsforslag kan accepteres af resolutionens forslagsstiller, hvorved det formelle resolutionsudkast omgående ændres.
+
+# Hvis et formelt ændringsforslag ikke accepteres, eller en af støtterne til resolutionen ikke er enig med forslagsstillerens accept af et formelt ændringsforslag, holdes en særskilt afstemning om dette.
+
+# Hvis andre ikke kan lide et ændringsforslag, som er accepteret af den oprindelige forslagsstiller, kan de foreslå en anden ændring for at fjerne den tidligere ændring (igen skal de leve op til kravene om forslagsstiller og støtte(r).)
+
+# Forslagsstilleren af en resolution kan foreslå revideringer af formuleringen af ændringensforslaget; disse træder i kraft hvis forslagsstilleren af ændringsforslaget er enig og ingen af støtterne protesterer. I så fald stemmes der om det reviderede ændringsforslag i stedet for det oprindelige.
+
+# Forslagsstilleren af en resolution kan foretage ændringer for at rette mindre fejl (for eksempel stavefejl eller selvmodsigelser) eller ændringer som ikke forandrer meningen, såfremt ingen protesterer indenfor 24 timer. I disse tilfælde starter minimumsdiskussionsperioden ikke igen.
+
+2~a2 A.2. Afstemning
+
+# Forslagsstilleren eller en støtte til en resolution eller et ændringsforslag kan bede om afstemning efter at minimumstiden for diskussion (hvis en sådan findes) er gået.
+
+# Foreslagsstilleren eller en støtte til en resolution kan bede om en afstemning vedrørende resolutionen eller alle beslægtede ændringsforslag.
+
+# Personen, der beder om en afstemning, fremsætter hvad vedkommende mener resolutionens og alle relevante ændringsforslags ordlyd skal være, og dermed hvilken udformning afstemningen skal have. Dog er det projektsekretæren som træffer den endelige beslutning - se §§ 7.1(1), 7.1(3), og A.3(4).
+
+# Den minimale diskussionsperiode regnes fra det tidspunkt, det sidste formelle ændringsforslag blev accepteret eller fra det tidspunkt hele resolutionen blev fremsat, hvis ingen ændringer er blevet foreslået og accepteret.
+
+2~a3 A.3. Afstemningsprocedure
+
+# Der stemmes på hver resolution og dennes beslægtede ændringsforslag i en enkelt afstemning, der indeholder en valgmulighed som er den originale resolution, hvert ændringsforslag, samt et standardvalg (hvor det er muligt).
+
+# Standardvalget må ikke have krav om et absolut flertal. Valgmuligheder som ikke eksplicit har krav om absolut flertal, har et 1:1-krav.
+
+# Stemmerne tælles jf. reglerne i A.6. Standardvalget er "Yderligere diskussion" ("Further Discussion"), med mindre andet er angivet.
+
+# I tvivlstilfælde skal projektsekretæren afgøre procedurespørgsmål.
+
+2~a4 A.4. Tilbagetrukne resolutioner og ikke-accepterede ændringsforslag
+
+Foreslagsstilleren af en resolution eller et ændringsforslag som ikke er accepteret, kan trække disse tilbage. I så fald kan andre foreslagsstillere overtage og holde resolutionen eller ændringsforslaget i live, dermed bliver den første person der gør dette, den nye foreslagsstiller og de andre bliver støtter, hvis de ikke allerede er det.
+
+En støtte til en resolution eller en ændring kan trække sig tilbage (med mindre resolutionen allerede er blevet accepteret).
+
+Hvis foreslagsstillers og/eller støttes tilbagetrækning betyder at resolutionen ikke har en foreslagsstiller eller der ikke er støtter nok, holdes der ikke en afstemning, med mindre dette udredes før resolutionen udløber.
+
+2~a5 A.5. Udløb
+
+Hvis en foreslået resolution ikke er blevet diskuteret, ændret, stemt på eller på anden måde taget hånd om i fire uger, kan sekretæren udsende en besked om, at den betragtes som tilbagetrukket. Hvis ingen af foreslagets støtter har indvendiger, trækkes foreslaget tilbage.
+
+Sekretæren kan også vedlægge forslag til hvordan man fortsætter, hvis det er relevat.
+
+2~a6 A.6. Stemmeoptælling
+
+# Hver vælgers stemme prioriterer valgmulighederne. Man behøver ikke at prioritere alle valgmulighederne. Prioriterede valgmuligheder betragtes som foretrukne fremfor valgmuligheder, der ikke er prioriteret. Vælgere kan give valgmuligheder samme prioritet. Valgmuligheder, der ikke er prioriteret, betragtes som ligestillede med hinanden. Nærmere oplysninger om hvordan stemmesedlerne skal udfyldes, vil være vedlagt valgindkaldelsen.
+
+# Hvis det beslutningsdygtige antal er R, vil enhver valgmulighed som ikke er standardvalget og som ikke modtager mindst R stemmer, der prioriterer den mulighed højere end standardvalget, vil ikke blivetaget i betragtning.
+
+# Alle (ikke-standard-) valgmuligheder, der ikke overgår standardvalgmuligheden med dens krævede flertalsgrad, tages ikke i betragtning.
+
+_# Med de to valgmuligheder A og B, er V(A,B) antallet af vælgere der foretrækker mulighed A fremfor mulighed B.
+
+_# Valgmulighed A overgår standardvalgmulighed D med flertalsgraden N, hvis V(A,D) er større end N * V(D,A).
+
+_# Hvis et absolut flertal på S:1 er krævet af A, er dennes flertalsgrad S; ellers er flertalsgraden 1.
+
+# Ud fra listen over valgmuligheder der tages i betragtning, genereres en liste over parvise nederlag.
+
+_# Valgmulighed A overgår mulighed B, hvis V(A,B) er større end V(B,A).
+
+# Ud fra en liste over parvise nederlag (som tages i betragtning), genereres en liste over transitive nederlag.
+
+_# Valgmulighed A overgår transitivt mulighed C, hvis A overgår C eller hvis der er en en mulighed B, hvor A overgår B OG B transitivt overgår C.
+
+# Ud fra sættet af transitive nederlag konstruere et Schwartz-sæt.
+
+_# Valgmulighed A er i Schwartz-sættet hvis, for alle B-muligheders vedkommende, A transitivt overgår B, eller B ikke overgår A transitivt.
+
+# Hvis der er nederlag mellem valgmuligheder i Schwartz-sættet, ses der bort fra de svageste af sådanne nederlag i listen over parvise nederlag, og man springer tilbage til trin 5.
+
+_# Nederlaget (A,X) er svagere end nederlaget (B,Y), hvis V(A,X) er mindre end V(B,Y). Hvis (A,X) desuden er svagere end (B,Y), hvis V(A,X) er lig med V(B,Y) og V(X,A) er større end V(Y,B).
+
+_# Et svageste nederlag, er et nederlag hvortil der ikke er et svagere nederlag. Der kan være mere end et af sådanne nederlag.
+
+# Hvis der ikke nogen nederlag i Schwartz-sættet, tages vinderen fra valgmulighederne i Schwartz-sættet. Hvis der kun er en af disse valgmuligheder, er den vinderen. Hvis der er flere valgmuligheder, afgørerer vælgeren med den afgørende stemme, hvem af disse valgmuligheder, der er vinderen.
+
+Bemærk: Valgmuligheder, som vælgerne prioriterer over standardvalgmuligheden, er muligheder de betragter som acceptable. Valgmuligheder, der prioriteres under standardvalgmuligheder, er muligheder, der betragtes som uacceptable.
+
+Når den generelle resolutionsprocedure anvendes, skal teksten som henviser til denne, fastsætte hvad der er tilstrækkeligt for at få et udkast til en resolution foreslået og/eller støttet, hvad minimumstiden for diskussion er, og hvad afstemningsperioden er. Den skal også fastsætte det eventuelle kvalificerede flertal og beslutningsdygtige antal, som skal anvendes.
+
+1~b B. Brug af sprog og typografi
+
+Nutid ("er", for eksempel) betyder at udtrykket er en regel i disse vedtægter. "Kan" og "skal" indikerer at personen eller organet kan anvende skøn. "Bør" betyder at det vil anses som en god ting om hvis sætningen følges, men den er ikke bindende. Tekst markeret som et citat, som dette, er baggrundsmateriale og udgør ikke en del af vedtægterne. Den kan kun anvendes til at hjælpe med at tolke teksten i tvivlstilfælde.
+
+Bemærk: Dette er en oversættelse af det originale engelsksprogede dokument. Brug altid originalen i diskussioner om vedtægterne, da denne dansksprogede udgave er oversætterens fortolkning, som desuden kan indeholde fejl og misforståelser.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/da/debian_constitution_v1.3.sst b/debian/data/doc/sisu/markup-samples/samples/v3/da/debian_constitution_v1.3.sst
new file mode 100644
index 00000000..3ddb7708
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/da/debian_constitution_v1.3.sst
@@ -0,0 +1,514 @@
+% SiSU 2.0
+
+@title: Debians vedtægter
+ :subtitle: Debian-projektets vedtægter (v1.3)
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution;language:Danish
+
+@date:
+ :published: 2003-10-29
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2003-10-29
+ :available: 2003-10-29
+ :modified: 2003-10-29
+
+@language:
+ :document: Danish
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.da.html <br>"Debian" og Debians logo http://www.debian.org/logos/ er varemærker tilhørende Software in the Public Interest, Inc.
+ :license: Dette materiale må kun distribueres i henhold til vilkårene beskrevet i Open Publication License, udkast (draft) v1.0 eller senere (du kan læse vores lokale kopi http://www.debian.org/opl, den seneste version er normalt tilgængelig på http://www.opencontent.org/openpub/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.3 blev godkendt den 24. september 2006. Erstatter version 1.2 godkendt den 29. oktober 2003 og version 1.1 godkendt den 21. juni 2003, der erstattede version 1.0 som blev godkendt den 2. december 1998.<br>Dette er en oversættelse af det originale engelsksprogede dokument http://www.debian.org/license.en.html. <br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.3.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Debians vedtægter
+
+:B~ Debian-projektets vedtægter (v1.3)
+
+1~pre [Prefix]-#
+
+{ Version 1.3 }http://www.debian.org/devel/constitution.1.3 blev godkendt den 24. september 2006. Erstatter { version 1.2 }http://www.debian.org/devel/constitution.1.2 godkendt den 29. oktober 2003 og { version 1.1 }http://www.debian.org/devel/constitution.1.1 godkendt den 21. juni 2003, der erstattede { version 1.0 }http://www.debian.org/devel/constitution.1.0 som blev godkendt den 2. december 1998.
+
+1~1 § 1. Introduktion
+
+Debian-projektet er en sammenslutning af personer, som har det fælles mål at udvikle et frit tilgængeligt styresystem.
+
+Dette dokument beskriver organisationsstrukturen for formelle beslutninger i projektet. Det beskriver ikke projektets mål eller hvordan vi opfylder disse, og indeholder ingen retningslinier, bortset fra de retningslinier som direkte vedrører beslutningsprosessen.
+
+1~2 § 2. Beslutningsdygtige organer og -personer
+
+Enhver beslutning i projektet er omfattet af en eller flere af følgende:
+
+# Udviklerne, via en fælles resolution eller et valg;
+
+# Projektlederen;
+
+# Den tekniske komité og/eller dennes formand;
+
+# Den individuelle udvikler som arbejder med en bestemt opgave;
+
+# Delegater udnævnt af projektlederen til at varetage særlige opgaver;
+
+# Projektsekretæren.
+
+Resten af dette dokument vil primært beskrive disse organers fuldmagter, deres sammensætning og udnævnelse, og procedurer for vedtagelser. En persons eller et organs fuldmagt kan i visse tilfælde blive genstand for gennemsyn af andre; i så fald vil det fremgå af afsnittet om det organ, der står for dette. I listen ovenfor er hver person eller hvert organ stort set anført før de personer eller organer de kan (hjælpe til med at) udnævne, og hvis beslutninger de kan ophæve - men ikke alle, der er anført tidligere, kan ophæve beslutninger fortaget af alle som er anført senere.
+
+2~2.1 § 2.1. Generelle regler
+
+# Intet i disse vedtægter forpligter nogen til at arbejde for projeket. En person, der ikke vil udføre en opgave, som er blevet uddelegeret eller pålagt vedkommende, behøver at gøre det. Derimod kan man ikke aktivt modarbejde regler eller beslutninger, som er foretaget korrekt i henhold til reglerne.
+
+# En person kan bestride flere hverv, bortset fra at projektlederen, projektsekretæren og formanden for den tekniske komité skal være forskellige personer, og lederen kan ikke udnæve sig selv, som sin egen delegat.
+
+# En person kan til enhver tid forlade projektet eller fratræde et særskilt hverv vedkommende har, ved offentligt at erklære dette.
+
+1~3 § 3. Individuelle udviklere
+
+2~3.1 § 3.1. Fuldmagt
+
+En individuel udvikler kan
+
+# tage tekniske og ikke-tekniske beslutninger med hensyn til sit eget arbejde;
+
+# foreslå og støtte udkast til generelle resolutioner;
+
+# foreslå sig selv som kandidat til projektleder i valg;
+
+# stemme på generelle resolutioner og i ledervalg.
+
+2~3.2 § 3.2. Sammensætning og udnævnelse
+
+# Udviklere er frivillige som er enige om at fremme projektets mål for så vidt som de deltager i det, og som vedligeholder pakke(r) for projektet eller gør andet arbejde, som projeketlederens delegater anser for værdifuldt.
+
+# Projektlederens delegater kan vælge ikke at optage nye udviklere, eller at ekskludere nuværende udviklere. Hvis udviklerne mener at delegaterne misbruger deres autoritet, kan de selvfølgelig ophæve en beslutning via en generel resolution - se § 4.1(3) og § 4.2.
+
+2~3.3 § 3.3. Fremgangsmåder
+
+Udviklerne kan foretage disse beslutninger efter eget skøn.
+
+1~4 § 4. Udviklerne via generel resolution eller et valg
+
+2~4.1 § 4.1. Fuldmagt
+
+Udviklerne kan sammen:
+
+# Udnævne eller afsætte projektlederen.
+
+# Ændre disse vedtægter med et 3:1-flertal.
+
+# Træffe eller ophæve enhver beslutning autoriseret af projektlederen eller en delegat.
+
+# Træffe eller ophæve enhver beslutning autoriseret af den tekniske komité, såfremt de er enige med et 2:1-flertal.
+
+# Udgive, erstatte og tilbagetrække ikke-tekniske retningslinier og erklæringer.
+
+Dette inkluderer dokumenter som forklarer projektmål, dets forhold til andre organer indenfor fri software, samt ikke-tekniske vejledninger som de fri software-licensbetingelser, som Debians programmel skal leve op til.
+
+Det kan også være stillingtagen til aktuelle emner.
+
+_# Et grundlæggende dokument er et dokument eller en bekendtgørelse, der betragtes som kritisk for projekts arbejde og formål.
+
+_# De grundlæggende dokumenter er det arbejde som er udmundet i Debian sociale kontrake og Debians retningslinier for fri software.
+
+_# Et grundlæggende dokument kræver et 3:1-flertal for dets erstatning. Nye grundlæggende dokumenter udgives og eksisterende dokumenter trækkes tilbage ved at føje til listen over grundlæggende dokumenter i disse vedtægter.
+
+# Træffe beslutninger om forvaltede ejendele til formål med relation til Debian. (Se § 9.1).
+
+# I tilfælde af uenighed mellem projektlederen og den nuværende sekretær, udnævne en ny sekretær.
+
+2~4.2 § 4.2. Fremgangsmåde
+
+# Udviklerne følger de generelle resolutionsprocedurer beskrevet nedenfor. En resolution eller ændring betragtes som introduceret, hvis den er foreslået af en hvilken som helst udvikler og mindst K andre udviklere støtter den, eller hvis den er foreslået af projektlederen eller den tekniske komité.
+
+# Udsættelse af en resolution foretaget af projektlederen eller dennes delegater:
+
+_# Hvis projektlederen, dennes delegater eller den tekniske komité har truffet en beslutning, kan udviklerne ophæve denne ved at vedtage en resolution derom, se § 4.1(3).
+
+_# Hvis en sådan resolution støttes af mindst 2K udviklere eller hvis den er foreslået af den tekniske komité, vil resolutionen omgående tilsidesætte beslutningen (såfremt resolutionen selv siger dette).
+
+_# Hvis den oprindelige beslutning var at ændre en diskussionsperiode eller en stemmeperiode, eller hvis resolutionens formål er at ophæve en beslutning foretaget af den tekniske komité, behøver kun K udviklere at støtte resolutionen, for omgående at kunne tilsidesætte beslutningen.
+
+_# Hvis beslutningen er tilsidesat, holdes omgående en afstemning for at afgøre om beslutningen skal opretholdes indtil en fuldstændig afstemning om beslutningen kan holdes, eller om udførslen af den oprindelige beslutning skal udsættes indtil da. Der findes ikke et beslutningsdygtigt antal stemmer i denne omgående, proceduriske afstemning.
+
+_# Hvis projektlederen (eller dennes delegater) trækker den oprindelige beslutning tilbage, bliver det uaktuelt at holde afstemningen og den vil ikke blive afholdt.
+
+# Stemmer indsamles af projektsekretæren. Stemmerne og afstemningsresultatet offentliggøres ikke i stemmeperioden; efter afstemningen opremser projektsekretæren alle de afgivne stemmer, Afstemningsperioden er to uger, men projektlederen kan tilføje eller fjerne op til en uge.
+
+# Minimumstiden for diskussion er to uger, men projektlederen kan tilføje eller fjerne op til en uge. Projektlederen har den afgørende stemme. Det beslutningsdygtige antals stemmer er 3Q.
+
+# Forslag, støtte, ændringer, stemmeopråb og andre formelle handlinger foregår via erklæringer på en offentlig tilgængelig elektronisk postliste udvalgt af projektlederens delegat(er); alle udviklere har skriveadgang til den.
+
+# Stemmer afgives via e-mail på en måde der bestemmes af sekretæren. Sekretæren bestemmer for hver afstemning hvorvidt vælgerne kan ændre deres stemmer.
+
+# Q er halvdelen af kvadratroden af antallet af udviklere. K er den mindste af Q og 5. Q og K behøver ikke at være heltal, og de afrundes ikke.
+
+1~5 § 5. Projektlederen
+
+2~5.1 § 5.1. Fuldmagt
+
+Projektlederen kan:
+
+# Udnævne delegater eller uddelegere beslutninger til den tekniske komité.
+
+Lederen kan beskrive en opgave med løbende ansvar eller en særskilt beslutning. I begge tilfælde overføres denne til en anden udvikler eller til den tekniske komité.
+
+Efter en særskilt beslutning er blevet uddelegeret og afgjort, kan projektlederen ikke trække uddelegeringen tilbage. derimod kan en løbende uddelegerning til en bestemt opgave trækkes tilbage.
+
+# Give hjemmel til andre udviklere.
+
+Projektlederen kan udgive støtteerklæringer til andres synspunkter eller andre projektmedlemmer, uden at være blevet bedt om det. Disse støtteerklæringer er gyldige, hvis, og kun hvis, lederen ville have haft fuldmagt til at træffe den foreliggende beslutning.
+
+# Foretage beslutninger som kræver omgående handling.
+
+Dette gælder ikke beslutninger som gradvist er blevet påtrængende på grund af manglende, relevant handling, med mindre der er en fastsat frist.
+
+# Foretage beslutninger som ingen andre har ansvaret for.
+
+# Fremstille udkast til generelle resolutioner og ændringsforslag.
+
+# Sammen med den tekniske komité udpege nye medlemmer til komitéen. (Se § 6.2.)
+
+# Afgive en afgørende stemme i udviklernes afstemninger.
+
+Projektlederen har også almindelig stemmeret i sådanne afstemninger.
+
+# Ændre diskussionsperioden for udviklernes afstemninger (som beskrevet ovenfor).
+
+# Lede diskussioner blandt udviklerne.
+
+Projektlederen bør prøve at deltage i diskussioner blandt udviklerne på en hjælpsom måde, som søger at bringe diskussionen på rette kurs mod sagens kerne. Projektlederen bør ikke bruge lederpositionen til at fremme sine egne personlige synspunkter.
+
+# I konsultation med udviklerne, træffe beslutninger der vedrører forvaltede ejendele i forbindelse med Debian. (Se § 9.). Sådanne beslutninger kommunikeres til medlemmerne af projektlederen eller dennes delegat(er). Større udgifter skal foreslås og diskuteres på postlisten før beløbet erlægges.
+
+# Tilføje eller fjerne organisationer fra listen over betroede organisationer (se § 9.3) som er autoriserede til at modtage og være i besiddelse af ejendele for Debian. Evaluering og diskussion førende til sådanne beslutninger finder sted på en elektronisk postliste udpeget af projektlederen eller denne delgat(er), på hvilken alle udviklere må skrive. Der er en minimal diskussionstid på to uger før en organisation må blive føjet til listen over betroede organisationer.
+
+2~5.2 § 5.2. Udnævnelse
+
+# Projektlederen vælges af udviklerne.
+
+# Valget begynder ni uger før lederpositionen bliver ledig eller (hvis det ikke allerede er for sent) omgående.
+
+# I de følgende tre uger kan enhver udvikler nominere sig selv som projektlederkandidat.
+
+# I de efterfølgende tre uger kan der ikke nomineres flere kandidater; kandiaterne bør anvende dette tidsrum til deres valgkamp (for at gøre opmærksom på sig selv og sine synspunkter). Hvis der ikke er nogen kandidater efter nomineringsperioden er slut, bliver perioden udvidet med yderligere tre uger, om nødvendigt gentagne gange.
+
+# De næste tre uger er valgperioden, hvori udviklerene kan stemme. Afstemningen i ledervalg er hemmelig, selv efter afstemningen er afsluttet.
+
+# Valget vil være mellem de kandidater, der har nomineret sig selv og som ikke har trukket sig tilbage, samt Ingen af de nævnte ("None of the Above"). Hvis Ingen af de nævnte vinder valget, bliver denne procedure gentaget, om nødvendigt mange gange.
+
+# Beslutningen træffes ved hjælp af den metode, som er beskrevet i afsnit § A.6 i de generelle resolutionsprocedurer. Det beslutningsdygtige antal er det samme, som ved en generel resolution (§ 4.2), og standardvalget er Ingen af de nævnte.
+
+# Projektlederen vælges for et år ad gangen.
+
+2~5.3 § 5.3. Fremgangsmåde
+
+Projektlederen bør prøve at træffe beslutninger som er i tråd med konsensus blandt udviklerne.
+
+Hvor det er praktisk bør projektlederen på en uformel måde bede om udviklernes synspunkter.
+
+Projektlederen bør undgå at lægge for megen vægt på sine egne synspunkter, når der træffes beslutninger i vedkommendes egenskab af leder.
+
+1~6 § 6. Teknisk komité
+
+2~6.1 § 6.1. Fuldmagt
+
+Den tekniske komité kan:
+
+# Træffe beslutninger om tekniske retningslinier.
+
+Deriblandt også indholdet af de tekniske retningslinier, udviklernes håndbogsmateriale, pakkeeksempler og hvordan ikke-eksperimentelle pakkeopbygningsværktøjer skal fungere. (I hvert tilfælde træffer den almindelige pakkevedligeholder af programmellet eller dokumentationen, de første beslutninger; se § 6.3(5).)
+
+# Afgøre tekniske spørgsmål hvor udviklernes ansvarsområder overlapper.
+
+I tilfælde hvor udviklere skal implementere kompatible tekniske retningslinier eller holdninger (for eksempel hvis de ikke er enige om prioriteringerne ved uforenlige pakker, eller om ejerskab af et kommandonavn, eller om hvilken pakke der er ansvarlig for en fejl som begge pakkevedligeholdere er enige om er en fejl, eller om hvem der bør være vedligeholder af en pakke), kan den tekniske komité afgøre sagen.
+
+# Træffe en beslutning når den bliver bedt om at gøre dette.
+
+Enhver person og ethvert organ kan uddelegere en af sine egne beslutninger til den tekniske komité eller bede om råd fra den.
+
+# Tilsidesætte en udviklers beslutning (kræver et 3:1-flertal)
+
+Den tekniske komité kan bede en udvikler om at benytte en bestemt fremgangsmåde, selvom udvikleren ikke ønsker det; dette kræver et 3:1-flertal. For eksempel kan komitéen komme frem til at en klage fremsat i en fejlrapport er gyldig og at indsenderens foreslåede løsning bør iværksættes.
+
+# Give råd.
+
+Den tekniske komité kan give formelle erklæringer om sit syn på enhvert emne. Individuelle medlemmer kan selvfølgelig give uformelle erklæringer om deres synspunkter og om komitéens sandsynlige synspunkter.
+
+# Sammen med projektlederen udnævne nye medlemmer til sig selv eller fjerne nuværende medlemmer. (Se § 6.2.)
+
+# Udnævne formanden for den tekniske komité.
+
+Komitéen vælger formand blandt sine medlemmer. Medlemmerne af komitéen nomineres automatisk; valget starter en uge før stillingen bliver ledig (eller omgående, hvis det allerede er for sent). Medlemmerne kan stemme via offentlig tilkendegivelse for hvilket som helst komitémedlem, også sig selv. Der er intet standardvalg. Valget afsluttes når alle medlemmerne har stemt eller stemmeperioden er afsluttet. Resultatet afgøres ved hjælp af den metode, som er angivet i § A.6 i de generelle resolutionsprocedurer.
+
+# Formanden kan vikariere for lederen, sammen med sekretæren
+
+Som beskrevet i § 7.1(2), kan formanden for den tekniske komité og projektsekretæren i fællesskab vikariere for lederen, hvis der ikke er en leder.
+
+2~6.2 § 6.2. Sammensætning
+
+# Den tekniske komité består af op til otte udviklere og bør normalt have mindst fire medlemmer.
+
+# Hvis det er mindre end otte medlemmer, kan den tekniske komité anbefale ny(e) medlem(mer) til projektlederen, som (på egen hånd) kan vælge at udnævne dem eller ej.
+
+# Hvis der er fem eller færre medlemmer, kan den tekniske komité udnævne ny(e) medlem(mer) indtil antallet af medlemmer når seks.
+
+# Når der har været fem eller færre medlemmer i mindst en uge, kan projektlederen udnævne nye medlem(mer) indtil antallet af medlemmer når seks, med mindst en uges mellemrum for hver udnævnelse.
+
+# Hvis den tekniske komité og projektlederen er enige kan de fjerne eller erstatte et nuværende medlem af den tekniske komité.
+
+2~6.3 § 6.3. Fremgangsmåde
+
+# Den tekniske komité anvender den generelle resolutionsprocedure.
+
+Et udkast til en resolution eller ændring kan framsættes af ethvert medlem af den tekniske komité. Det er ingen minimumstid for diskussion; valgperioden varer i op til en uge eller indtil der ikke længere kan være nogen tvivl om resultatet. Medlemmerne kan ændre deres stemmer. Det beslutningsdygtige antal er to.
+
+# Detaljerede afstemningoplysninger
+
+Formanden har den afgørende stemme. Når den tekniske komité stemmer for at afgøre, om de skal tilsidesætte en afgørelse taget af en udvikler, der også er et medlem af komitéen, kan dette medlem ikke stemme (med mindre det er formanden, som i dette tilfælde kun kan benytte sin afgørende stemmeret).
+
+# Offentlig diskussion og afgørelser
+
+Diskussioner, udkast til resolutioner og ændringer og komitemedlemmernes stemmer offentliggøres på den tekniske komités offentlige diskussionsliste. Der er ikke en særskilt sekretær for komitéen.
+
+# Fortrolighed ved udnævnelser
+
+Den tekniske komité kan holde fortrolige diskussioner via privat e-mail eller en privat postliste, eller på andre måder diskutere udnævnelser til komitéen. Derimod skal stemmerne ved udnævnelser offentliggøres.
+
+# Ikke et detaljeret udviklingsarbejde
+
+Den tekniske komité giver sig ikke i kast med fremstilling af nye forslag og retningslinier. Sådant udviklingsarbejde bør foretages privat af personer eller grupper, og diskuteres i almindelige tekniske og udviklingsfora.
+
+Den tekniske komité begrænser sig selv til at vælge blandt, eller vælge et kompromis mellem, løsninger og afgørelser, der er blevet foreslået og er blevet drøftet tilpas meget andre steder.
+
+Medlemmer af den tekniske komité kan selvfølgelig deltage på egne vegne i alle aspekter af udviklings- og retningsliniearbejde.
+
+# Den teknisk komité træffer kun afgørelser som en sidste udvej
+
+Den tekniske komité træffer ikke en teknisk afgørelse før der uden held har været gjort forsøg på at løse problemet ved konsensus, med mindre den er blevet bedt om at træffe en afgørelse af personen eller organet, der normalt ville have haft ansvar for at gøre dette.
+
+1~7 § 7. Projektsekretæren
+
+2~7.1 § 7.1. Fuldmagt
+
+Sekretæren:
+
+# Indsamler stemmer fra udviklerne, finder ud af hvor mange udviklere der er og hvem de er, når dette kræves af vedtægterne.
+
+# Kan vikariere for lederen, i fællesskab med formanden for den tekniske komité.
+
+Hvis der ikke er en projektleder, kan formanden for den tekniske komité og projektsekretæren træffe afgørelser ved enighed, hvis de mener at det er vigtigt at gøre dette.
+
+# Dømmer i stridigheder om tolkning af vedtægterne.
+
+# Kan uddelegere dele af eller hele sin fuldmagt til andre, eller til enhver tid trække en sådan uddelegering tilbage.
+
+2~7.2 § 7.2. Udnævnelse
+
+Projektsekretæren udnævnes af projektlederen og den forrige projektsekretær.
+
+Hvis projektlederen og den forrige projektsekretær ikke kan blive enige om en ny udnævnelse, skal de bede udviklerne om at udnævne en ny sekretær gennem en generel beslutning.
+
+Hvis der ikke er en projektsekretær eller den forrige sekretær ikke kan træffes og ikke har uddelegeret sin fuldmagt til en sådan beslutning, kan beslutningen træffes eller uddelegeres af formanden for den tekniske komité, som fungerende sekretær.
+
+Projektsekretæren er valgt for et år ad gangen, hvorefter en ny (gen)udnævnelse er nødvendig.
+
+2~7.3 § 7.3. Fremgangsmåde
+
+Projektsekretæren bør træffe afgørelser som er retfærdige og rimelige, og helst i overensstemmelse med konsensus blandt udviklerne.
+
+Når projektsekretæren og formanden for den tekniske komité i fællesskab vikarierer for en projektleder som ikke kan træffes, bør de kun træffe beslutninger som er helt nødvendige og kun når det er i overensstemmelse med konsensus blandt udviklerne.
+
+1~8 § 8. Projektlederens delegater
+
+2~8.1 § 8.1. Fuldmagt
+
+Projektlederens delegater:
+
+# har fået uddelegeret en fuldmagt fra projektlederen;
+
+# kan træffe visse afgørelser som lederen ikke kan tage på egen hånd, deriblandt optagelse eller afvisning af udviklere, eller udnævne folk der ikke håndterer pakker, som udviklere. Dette er for at undgå en magtkoncentration hos projektlederen, særligt med hensyn til udviklermedlemskab.
+
+2~8.2 § 8.2. Udnævnelse
+
+Delegaterne udnævnes af projektlederen, og lederen kan udskifte dem, som han finder det passende. Projektlederen kan ikke gøre udnævnelse betinget af at delegaten træffer bestemte afgørelser, lederen kan heller ikke ophævne en beslutning truffet af en delegat.
+
+2~8.3 § 8.3. Fremgangsmåde
+
+Delegater kan til enhver tid træffe afgørelser, men bør prøve at opnå gode tekniske vilkår og/eller følge konsensus.
+
+1~9 § 9. Ejendele der forvaltes på vegne af Debian
+
+I de fleste af verdens jurisdiktioner er Debian-projektet ikke i en situation hvor det direkte må være i besiddelse af midler eller andre ejendele. Derfor er det nødvendigt at ejendele ejes af enhver af en række organisationer, som beskrevet i § 9.2.
+
+Traditionelt var SPI den eneste organisation, der var autoriseret til at forvalte ejendele og beløb for Debian-projektet. SPI blev etableret i USA, for der at forvalte beløb.
+
+SPI og Debian er adskilte organisationer, der har nogle fælles mål. Debian er taknemlig for det juridiske støtteapparat, som SPI tilbyder.
+
+2~9.1 § 9.1. Relationer til tilknyttede organisationer
+
+# Debian-udviklere bliver ikke agenter for eller ansatte af organisationer der forvalter ejendele for Debian, eller af hinanden, eller af persioner med myndighed i Debian-projektet, blot ved at være Debian-udviklere. En person der fungerer som udvikler gør dette som en individuel person, på egne vegne. Sådanne organisationer kan, af egen kraft, etablere relationer mellem individer der også er Debian-udviklere.
+
+2~9.2 § 9.2. Autoritet
+
+# En organisation der forvalter ejendele for Debian har ingen autoritet over Debians tekniske eller ikke-tekniske beslutninger, bortset fra at ingen beslutninger taget af Debian hvad angår ejendele der forvaltes af organisationen må kræve at denne handler uden for sin juridiske autoritet.
+
+# Debian har ingen autoritet over en organisation der forvalter ejendele for Debian, bortset fra over de ejendele der forvaltes for Debian.
+
+2~9.3 Betroede organisationer
+
+Alle donationer til Debian-projektet skal ske til en af de organisationer, som projektlederen (eller en delegat) har autoriseret til at forvalte ejendele til anvendelse af Debian-projektet.
+
+Organisationer der forvalter ejendele for Debian bør påtage sig passende forpligtelser ved forvaltning af sådanne ejendele.
+
+Debian vedligeholder en offentlig liste over betroede organisationer, der accepterer donationer og forvalter ejendele for Debian (deriblandt håndgribelige og intellektuelle ejendele), indeholdende disse organisationers tilsagn til hvordan disse ejendele vil blive forvaltet.
+
+1~a A. Generel resolutionsprocedure
+
+Disse regler gælder fælles beslutninger truffet af komitéer og ved afstemninger, som beskrevet ovenfor.
+
+2~a1 A.1. Forslag
+
+Den formelle procedure begynder når et udkast til en beslutning er foreslået og støttet, som krævet.
+
+2~a1a A.1. Diskussion og ændring
+
+# Efter forslaget er fremsat, kan resolutionen diskuteres. Ændringsforslag kan gøres formelle ved at fremsætte dem og skaffe støtter jævnfør kravene for nye resolutioner, eller direkte af forslagsstilleren af det oprindelige forslag.
+
+# Et formelt ændringsforslag kan accepteres af resolutionens forslagsstiller, hvorved det formelle resolutionsudkast omgående ændres.
+
+# Hvis et formelt ændringsforslag ikke accepteres, eller en af støtterne til resolutionen ikke er enig med forslagsstillerens accept af et formelt ændringsforslag, holdes en særskilt afstemning om dette.
+
+# Hvis andre ikke kan lide et ændringsforslag, som er accepteret af den oprindelige forslagsstiller, kan de foreslå en anden ændring for at fjerne den tidligere ændring (igen skal de leve op til kravene om forslagsstiller og støtte(r).)
+
+# Forslagsstilleren af en resolution kan foreslå revideringer af formuleringen af ændringensforslaget; disse træder i kraft hvis forslagsstilleren af ændringsforslaget er enig og ingen af støtterne protesterer. I så fald stemmes der om det reviderede ændringsforslag i stedet for det oprindelige.
+
+# Forslagsstilleren af en resolution kan foretage ændringer for at rette mindre fejl (for eksempel stavefejl eller selvmodsigelser) eller ændringer som ikke forandrer meningen, såfremt ingen protesterer indenfor 24 timer. I disse tilfælde starter minimumsdiskussionsperioden ikke igen.
+
+2~a2 A.2. Afstemning
+
+# Forslagsstilleren eller en støtte til en resolution eller et ændringsforslag kan bede om afstemning efter at minimumstiden for diskussion (hvis en sådan findes) er gået.
+
+# Foreslagsstilleren eller en støtte til en resolution kan bede om en afstemning vedrørende resolutionen eller alle beslægtede ændringsforslag.
+
+# Personen, der beder om en afstemning, fremsætter hvad vedkommende mener resolutionens og alle relevante ændringsforslags ordlyd skal være, og dermed hvilken udformning afstemningen skal have. Dog er det projektsekretæren som træffer den endelige beslutning - se §§ 7.1(1), 7.1(3), og A.3(4).
+
+# Den minimale diskussionsperiode regnes fra det tidspunkt, det sidste formelle ændringsforslag blev accepteret eller fra det tidspunkt hele resolutionen blev fremsat, hvis ingen ændringer er blevet foreslået og accepteret.
+
+2~a3 A.3. Afstemningsprocedure
+
+# Der stemmes på hver resolution og dennes beslægtede ændringsforslag i en enkelt afstemning, der indeholder en valgmulighed som er den originale resolution, hvert ændringsforslag, samt et standardvalg (hvor det er muligt).
+
+# Standardvalget må ikke have krav om et absolut flertal. Valgmuligheder som ikke eksplicit har krav om absolut flertal, har et 1:1-krav.
+
+# Stemmerne tælles jf. reglerne i A.6. Standardvalget er "Yderligere diskussion" ("Further Discussion"), med mindre andet er angivet.
+
+# I tvivlstilfælde skal projektsekretæren afgøre procedurespørgsmål.
+
+2~a4 A.4. Tilbagetrukne resolutioner og ikke-accepterede ændringsforslag
+
+Foreslagsstilleren af en resolution eller et ændringsforslag som ikke er accepteret, kan trække disse tilbage. I så fald kan andre foreslagsstillere overtage og holde resolutionen eller ændringsforslaget i live, dermed bliver den første person der gør dette, den nye foreslagsstiller og de andre bliver støtter, hvis de ikke allerede er det.
+
+En støtte til en resolution eller en ændring kan trække sig tilbage (med mindre resolutionen allerede er blevet accepteret).
+
+Hvis foreslagsstillers og/eller støttes tilbagetrækning betyder at resolutionen ikke har en foreslagsstiller eller der ikke er støtter nok, holdes der ikke en afstemning, med mindre dette udredes før resolutionen udløber.
+
+2~a5 A.5. Udløb
+
+Hvis en foreslået resolution ikke er blevet diskuteret, ændret, stemt på eller på anden måde taget hånd om i fire uger, kan sekretæren udsende en besked om, at den betragtes som tilbagetrukket. Hvis ingen af foreslagets støtter har indvendiger, trækkes foreslaget tilbage.
+
+Sekretæren kan også vedlægge forslag til hvordan man fortsætter, hvis det er relevat.
+
+2~a6 A.6. Stemmeoptælling
+
+# Hver vælgers stemme prioriterer valgmulighederne. Man behøver ikke at prioritere alle valgmulighederne. Prioriterede valgmuligheder betragtes som foretrukne fremfor valgmuligheder, der ikke er prioriteret. Vælgere kan give valgmuligheder samme prioritet. Valgmuligheder, der ikke er prioriteret, betragtes som ligestillede med hinanden. Nærmere oplysninger om hvordan stemmesedlerne skal udfyldes, vil være vedlagt valgindkaldelsen.
+
+# Hvis det beslutningsdygtige antal er R, vil enhver valgmulighed som ikke er standardvalget og som ikke modtager mindst R stemmer, der prioriterer den mulighed højere end standardvalget, vil ikke blivetaget i betragtning.
+
+# Alle (ikke-standard-) valgmuligheder, der ikke overgår standardvalgmuligheden med dens krævede flertalsgrad, tages ikke i betragtning.
+
+_# Med de to valgmuligheder A og B, er V(A,B) antallet af vælgere der foretrækker mulighed A fremfor mulighed B.
+
+_# Valgmulighed A overgår standardvalgmulighed D med flertalsgraden N, hvis V(A,D) er større end N * V(D,A).
+
+_# Hvis et absolut flertal på S:1 er krævet af A, er dennes flertalsgrad S; ellers er flertalsgraden 1.
+
+# Ud fra listen over valgmuligheder der tages i betragtning, genereres en liste over parvise nederlag.
+
+_# Valgmulighed A overgår mulighed B, hvis V(A,B) er større end V(B,A).
+
+# Ud fra en liste over parvise nederlag (som tages i betragtning), genereres en liste over transitive nederlag.
+
+_# Valgmulighed A overgår transitivt mulighed C, hvis A overgår C eller hvis der er en en mulighed B, hvor A overgår B OG B transitivt overgår C.
+
+# Ud fra sættet af transitive nederlag konstruere et Schwartz-sæt.
+
+_# Valgmulighed A er i Schwartz-sættet hvis, for alle B-muligheders vedkommende, A transitivt overgår B, eller B ikke overgår A transitivt.
+
+# Hvis der er nederlag mellem valgmuligheder i Schwartz-sættet, ses der bort fra de svageste af sådanne nederlag i listen over parvise nederlag, og man springer tilbage til trin 5.
+
+_# Nederlaget (A,X) er svagere end nederlaget (B,Y), hvis V(A,X) er mindre end V(B,Y). Hvis (A,X) desuden er svagere end (B,Y), hvis V(A,X) er lig med V(B,Y) og V(X,A) er større end V(Y,B).
+
+_# Et svageste nederlag, er et nederlag hvortil der ikke er et svagere nederlag. Der kan være mere end et af sådanne nederlag.
+
+# Hvis der ikke nogen nederlag i Schwartz-sættet, tages vinderen fra valgmulighederne i Schwartz-sættet. Hvis der kun er en af disse valgmuligheder, er den vinderen. Hvis der er flere valgmuligheder, afgørerer vælgeren med den afgørende stemme, hvem af disse valgmuligheder, der er vinderen.
+
+Bemærk: Valgmuligheder, som vælgerne prioriterer over standardvalgmuligheden, er muligheder de betragter som acceptable. Valgmuligheder, der prioriteres under standardvalgmuligheder, er muligheder, der betragtes som uacceptable.
+
+Når den generelle resolutionsprocedure anvendes, skal teksten som henviser til denne, fastsætte hvad der er tilstrækkeligt for at få et udkast til en resolution foreslået og/eller støttet, hvad minimumstiden for diskussion er, og hvad afstemningsperioden er. Den skal også fastsætte det eventuelle kvalificerede flertal og beslutningsdygtige antal, som skal anvendes.
+
+1~b B. Brug af sprog og typografi
+
+Nutid ("er", for eksempel) betyder at udtrykket er en regel i disse vedtægter. "Kan" og "skal" indikerer at personen eller organet kan anvende skøn. "Bør" betyder at det vil anses som en god ting om hvis sætningen følges, men den er ikke bindende. Tekst markeret som et citat, som dette, er baggrundsmateriale og udgør ikke en del af vedtægterne. Den kan kun anvendes til at hjælpe med at tolke teksten i tvivlstilfælde.
+
+Bemærk: Dette er en oversættelse af det originale engelsksprogede dokument. Brug altid originalen i diskussioner om vedtægterne, da denne dansksprogede udgave er oversætterens fortolkning, som desuden kan indeholde fejl og misforståelser.
+
+% Deutsch English español français Italiano 日本語 (Nihongo) polski Português Русский (Russkij) svenska
+
+% Sådan opsætter du standardsprogvalg for dokumenter
+
+% For at rapportere et problem med webstedet sendes en e-mail på engelsk til debian-www@lists.debian.org. Se Debians kontaktside for andre kontaktoplysninger.
+
+% Senest opdateret: Tirs 14. nov 2006 kl. 15.41.07 UTC
+% Ophavsretsbeskyttet © 1997-2006 SPI; Se licensbetingelserne
+% Debian er et registreret varemærke tilhørende Software in the Public Interest, Inc.
+
+% Debian-projektet
+
+% Vælg en server i nærheden af dig
+
+% Spring navigering over
+
+% * Om Debian
+% * Nyheder
+% * Få fat i Debian
+% * Support
+% * Udviklerhjørnet
+% * Sideoversigt
+% * Søg
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/da/debian_social_contract_v1.1.sst b/debian/data/doc/sisu/markup-samples/samples/v3/da/debian_social_contract_v1.1.sst
new file mode 100644
index 00000000..c22f142b
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/da/debian_social_contract_v1.1.sst
@@ -0,0 +1,138 @@
+% SiSU 2.0
+
+@title: Debians sociale kontrakt
+ :subtitle: Debian Social Contract (v1.1)
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:policy:social contract;GNU/Linux:debian:social contract;language:Danish
+
+@date:
+ :published: 2004-04-26
+ :created: 1997-07-05
+ :issued: 1997-07-05
+ :valid: 2004-04-26
+ :available: 2004-04-26
+ :modified: 2004-04-26
+
+@language:
+ :document: Danish
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.da.html <br>"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc.
+ :license: This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/social_contract
+ {Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
+
+@make:
+ :breaks: new=C; break=1
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Debians sociale kontrakt
+
+1~pre [Prefix]-#
+
+Version 1.1 blev vedtaget den 26. april 2004. Den erstattede version 1.0, som blev vedtaget den 5. juli 1997.
+
+Debian, der fremstiller Debian GNU/Linux-systemet, har skrevet Debians sociale kontrakt. Debians retningslinier for fri software (DFSG)-delen af kontrakten, oprindeligt et sæt løfter som vi er enige om at overholde, har fri software-fællesskabet taget til sig som basis for Open Source-definitionen (åben kildekode-definitionen).
+
+1~ Social kontrakt med fri software-fællesskabet
+
+2~ 1. Debian vil forblive 100 procent fri software
+
+De retningslinier vi bruger for at afgøre om et værk er "frit" stiller vi til rådighed i dokumentet "The Debian Free Software Guidelines", på dansk "Debians retningslinier for fri software". Vi lover at Debian-systemet og alle dets komponenter vil være frit tilgængelige jævnfør disse retningslinier. Vi vil støtte folk der udvikler og anvender både frie og ikke-frie værker på Debian. Vi vil aldrig lade systemet kræve anvendelse af et ikke-frit komponent.
+
+2~ 2. Vi vil give noget tilbage til fri software-fællesskabet
+
+Når vi udvikler nye komponenter til Debian-systemet, vil vi licensere dem på en måde som er i overensstemmelse med Debian retningslinier for fri software. Vi vil lave det bedste system vi kan, således at frit tilgængelige værker får stor udbredelse og anvendelse. Vi vil videregive ting så som fejlrettelser, forbedringer og brugerønsker til "opstrøms"-udviklerne af værker indeholdt i vores system.
+
+2~ 3. Vi vil ikke skjule problemer
+
+Hele vores database over fejlrapporter vil altid være åben for offentligheden. Rapporter som indsendes via Internet, vil med det samme kunne ses af andre.
+
+2~ 4. Vi prioriterer vore brugere og fri software højest
+
+Vi styres af brugernes og fri software-fællesskabets behov. Vi vil prioritere deres interesser højest. Vi vil understøtte vore brugeres behov for at kunne anvende mange forskellige computer-miljøer. Vi vil ikke gøre indsigelser mod ikke-frie værker der er beregnet til at køre på på Debian-systemer, eller forsøge at opkræve en afgift fra folk der udvikler eller anvender sådanne systemer. Vi vil tillade andre at fremstille distibutioner som indeholder både Debian-systemet og andre værker, uden at opkræve afgifter for det. For at fremme disse mål, vil vi stille et integreret system bestående af høj kvalitetsmateriale til rådighed, uden juridiske begrænsninger der kan forhindre sådanne anvendelser af systemet.
+
+2~ 5. Værker der ikke lever op til vore fri software-standarder
+
+Vi anerkender at nogle af vore brugere behøver programmer som ikke opfylder Debians retningslinier for fri software. Til det formål har vi oprettet områderne "contrib" (bidrag) og "non-free" (ikke-frit) i vores filarkiv. Pakkerne i disse områder udgør ikke en del af Debian-systemet, selvom de er opsat til brug sammen med Debian. Vi opfordrer cd-producenter til at læse licensbetingelser til pakkerne i disse områder og afgøre om de kan distribuere pakkerne på deres cd'er. Derfor, selvom ikke-frie værker ikke er en del af Debian, understøtter vi anvendelsen af dem og vi stiller infrastrukturen (som for eksempel vores fejlrapporteringssystem og postlister) til rådighed for ikke-frie pakker.
+
+1~ Debians retningslinier for fri software (DFSG)
+
+2~ 1. Fri videredistribution
+
+Et Debian-komponents licens må ikke forhindre nogen i at sælge eller forære programmet væk som en komponent i en samlet distribution, bestående af programmer fra flere forskellige kilder. Licensen må ikke kræve licenseringsafgifter eller lignende ved et sådant salg.
+
+2~ 2. Kildekode
+
+Programmet skal inkludere kildekode, og skal tillade distribution i form af både kildekode og et oversat program.
+
+2~ 3. Afledte værker
+
+Licensen skal tillade ændringer og afledte værker, og skal tillade at disse distribueres under de samme betingelser som det originale programs licens.
+
+2~ 4. Forfatterens kildekodes integritet
+
+Licensen må _kun_ begrænse distribuering af kildekoden i ændret form, hvis licensen tillader distribuering af "patch-filer" sammen med kildekoden med det formål at ændre programmet under oversættelse. Licensen skal eksplicit tillade distribution af programmer baseret på den ændrede kildekode. Licensen kan kræve at afledte værker har et andet navn eller versionsnummer end det originale program. (Dette er et kompromis. Debian-gruppen opfordrer alle forfattere til ikke at begrænse ændring af nogen filer, hverken kildekode eller oversat program.)
+
+2~ 5. Ingen diskrimination af personer eller grupper
+
+Licensen må ikke diskriminere nogen person eller gruppe af personer.
+
+2~ 6. Ingen diskrimination af anvendelsesområdet
+
+Licensen må ikke forhindre nogen i at bruge programmet indenfor et specifikt anvendelsesområde. Den må for eksempel ikke forhindre at programmet anvendes kommercielt eller i forbindelse med genetisk forskning.
+
+2~ 7. Distribution af licensen
+
+Rettighederne knyttet til programmet skal gælde alle, som programmet er videredistribueret til, uden at kræve yderligere licensering for disse parter.
+
+2~ 8. Licensen må ikke kun gælde Debian
+
+Rettighederne knyttet til programmet skal ikke være afhængig af at programmet er en del af Debian-systemet. Hvis programmet tages fra Debian og anvendes eller distribueres uden Debian, men ellers indenfor licensbetingelserne, skal alle parter som programmet er videredistribueret til, have de samme rettigheder som de licensbetingelser, der gives i forbindelse med Debian-systemet.
+
+2~ 9. Licensen må ikke smitte anden software
+
+Licensen må ikke lægge restriktioner på anden software som distribueres sammen med den licenserede software. For eksempel må licensen ikke insistere på, at alle andre programmer der distribueres på det samme medie er fri software.
+
+2~ 10. Eksempler på licenser
+
+"GPL"-, "BSD"-, og "Artistic"-licenserne er eksempler på licenser som vi betragter som værende "frie".
+
+Ean Schuessler foreslog at nedfælde vores "sociale kontrakt med fri software-fællesskabet". Det første udkast blev skrevet af Bruce Perens og blev fuldstændiggjort af de andre Debian-udviklere i løbet af en månedlang e-mail-konference i juni 1997, og dernæst accepteret som Debian-projektets offentlige retningslinier.
+
+Bruce Perens fjernede senere de Debian-specifikke referencer fra "Debians retningslinier for fri software", for at forfatte “Open Source-definitionen”.
+
+Andre organisationer må låne fra og basere sig på dette dokument. Angiv i givet fald venligst Debian-projektet som kilde.
+
+Tilbage til Debian-projektets hjemmeside.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/de/debian_constitution_v1.2.sst b/debian/data/doc/sisu/markup-samples/samples/v3/de/debian_constitution_v1.2.sst
new file mode 100644
index 00000000..d1609629
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/de/debian_constitution_v1.2.sst
@@ -0,0 +1,503 @@
+% SiSU 2.0
+
+@title: Debian-Verfassung
+ :subtitle: Verfassung für das Debian-Projekt (v1.2) [This Document has been Superseded by v1.3]
+
+@creator:
+ :author: Debian Project
+
+@date:
+ :published: 2003-10-29
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2003-10-29
+ :available: 2003-10-29
+ :modified: 2003-10-29
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.de.html <br>"Debian" und das Debian-Logo http://www.debian.org/logos/ sind Warenzeichen von Software in the Public Interest, Inc.<br>Dies ist die deutsche Übersetzung von "Debian's license" http://www.debian.org/license.en.html. In Zweifelsfällen ist das englische Original maßgeblich.
+ :license: Dieses Material darf nur unter den Bestimmungen, die in der Open Publication License, Draft v1.0 oder später (Sie können unsere lokale Kopie lesen http://www.debian.org/opl, die neuste Version ist normalerweise unter unter http://www.opencontent.org/openpub/ verfügbar) festgehalten sind, weitergegeben werden.
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution;language:German
+
+@language:
+ :document: German
+ :original: English
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+% @rights: http://www.debian.org/license Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/ <br>This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ). <br>"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc.
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2.default/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+:A~ Debian-Verfassung
+
+:B~ Verfassung für das Debian-Projekt (v1.2) [This Document has been Superseded by v1.3]
+
+1~pre [Prefix]-#
+
+Dies ist die am 29. Oktober 2003 ratifizierte Version 1.2. Sie ersetzt die am 21. Juni 2003 ratifizierte Version 1.1, welche ihrerseits die am 2. Dezember 1998 ratifizierte Version 1.0 ersetzt.
+
+1~ Einleitung
+
+/{Das Debian-Projekt ist ein Verband von Einzelpersonen, die die Schaffung eines freien Betriebssystem zu ihrem gemeinsamen Anliegen gemacht haben.}/
+
+Dieses Dokument beschreibt die Organisationsstruktur für formelle Entscheidungsfindung innerhalb des Projekts. Es beschreibt nicht die Ziele des Projekts oder wie es diese erreicht, und es enthält keine Richtlinien außer denen, die sich direkt auf den Prozess der Entscheidungsfindung beziehen.
+
+1~ Entscheidungsfindende Organe und Einzelpersonen
+
+Jede Entscheidung innerhalb des Projekts wird von einem oder mehreren der folgenden Organe und Einzelpersonen getroffen:
+
+# Den Entwicklern, durch einen Allgemeinen Beschluss oder eine Wahl.
+
+# Dem Projektleiter;
+
+# Dem Technischen Ausschuss und/oder seinem Vorsitzenden;
+
+# Dem an einer einzelnen Aufgabe arbeitenden Entwickler;
+
+# Vom Projektleiter für bestimmte Aufgaben ernannten Delegierten;
+
+# Dem Projekt-Schriftführer.
+
+Das meiste vom Rest dieses Dokuments beschreibt die Befugnisse dieser Organe, ihre Zusammensetzung und Ernennung und das Verfahren bei ihrer Entscheidungsfindung. Die Befugnisse einer Person oder eines Organs können der Überwachung und/oder Einschränkung durch Andere unterworfen sein; in diesem Fall gibt dies der Eintrag des überwachenden Organs oder der Person an. In der obigen Liste ist eine Person oder ein Organ in der Regel vor irgendwelchen Personen oder Organen aufgeführt, deren Entscheidungen sie aufheben können oder die sie ernennen (oder ihnen dabei helfen) – jedoch kann nicht jeder, der vorher aufgeführt wird, jeden, der nachher aufgeführt wird, überstimmen.
+
+2~ Allgemeine Vorschriften
+
+# Nichts in dieser Verfassung erlegt irgendjemandem die Verpflichtung auf, für das Projekt Arbeit zu verrichten. Eine Person, die eine an sie delegierte oder ihr zugewiesene Aufgabe nicht erledigen möchte, muss es nicht tun. Jedoch darf sie nicht diesen Vorschriften oder Entscheidungen, die nach diesen Vorschriften ordnungsgemäß getroffen wurden, aktiv entgegenwirken.
+
+# Eine Person kann verschiedene Ämter innehaben, mit der Ausnahme, dass sich der Projektleiter, der Projekt-Schriftführer und der Vorsitzende des Technischen Ausschusses unterscheiden müssen, und dass der Projektleiter sich nicht zu seinem eigenen Delegierten ernennen kann.
+
+# Eine Person kann das Projekt verlassen oder ein bestimmtes Amt zu jeder Zeit niederlegen, indem sie dies öffentlich erklärt.
+
+1~ Einzelne Entwickler
+
+2~ Befugnisse
+
+Ein einzelner Entwickler darf
+
+# jede technische oder nicht-technische Entscheidung hinsichtlich seiner eigenen Arbeit treffen;
+
+# einen Entwurf zu einem Allgemeinen Beschluss einbringen oder befürworten;
+
+# sich bei Wahlen selbst als Kandidat für das Amt des Projektleiters vorschlagen;
+
+# bei Allgemeinen Beschlüssen und bei Wahlen über die Leitung abstimmen.
+
+2~ Zusammensetzung und Ernennung
+
+# Entwickler sind Freiwillige, die sich darin einig sind, die Ziele des Projekts insofern zu fördern, als sie an ihm teilhaben, und die ein oder mehrere Pakete für das Projekt betreuen oder andere Arbeit verrichten, welche der oder die Delegierten des Projektleiters als lohnenswert erachten.
+
+# Der oder die Delegierten des Projektleiters können es vorziehen, keine neuen Entwickler aufzunehmen, oder vorhandene Entwickler auszuschließen. Wenn die Entwickler verspüren, dass die Delegierten ihre Autorität missbrauchen, können sie selbstverständlich die Entscheidung durch einen Allgemeinen Beschluss außer Kraft setzen - siehe §4.1(3), §4.2.
+
+2~ Verfahren
+
+Entwickler können diese Entscheidungen treffen, wie sie es für richtig halten.
+
+1~ Die Entwickler durch einen Allgemeinen Beschluss oder Wahl
+
+2~ Befugnisse
+
+Zusammen können die Entwickler
+
+# Den Projektleiter ernennen oder abberufen.
+
+# Diese Verfassung abändern, vorausgesetzt, sie stimmen dem mit einer 3:1-Mehrheit zu.
+
+# Jede vom Projektleiter oder einem Delegierten getroffene Entscheidung außer Kraft setzen.
+
+# Jede vom Technischen Ausschuss getroffene Entscheidung außer Kraft setzen, vorausgesetzt, sie stimmen dem mit einer 2:1-Mehrheit zu.
+
+# Nicht-technische schriftliche Richtlinien und Erklärungen herausgeben, ersetzen und zurückziehen.
+
+Diese beinhalten Dokumente, welche die Ziele des Projekts und seine Beziehung zu anderen Gebilden der Freien Software beschreiben, sowie nicht-technische Richtlinien wie die Lizenzbedingungen für Freie Software, die Debian-Software erfüllen muss.
+
+Sie können auch Positionserklärungen zu Tagesfragen hinzufügen.
+
+_# Ein Gründungsdokument ist ein Dokument oder eine Erklärung, die als entscheidend für den Auftrag und die Zwecke des Projekts betrachtet werden.
+
+_# Die Gründungsdokumente sind die Arbeiten mit dem Titel Debian-Gesellschaftsvertrag und Debian Richtlinien für freie Software.
+
+_# Ein Gründungsdokument benötigt eine 3:1-Mehrheit, um ersetzt zu werden. Durch Abändern der Liste der Gründungsdokumente in dieser Verfassung werden neue Gründungsdokumente herausgegeben und vorhandene zurückgezogen.
+
+# Zusammen mit dem Projektleiter und SPI Entscheidungen über mit Debian in Beziehung stehendes, treuhänderisch verwaltetes Eigentum treffen. (Siehe §9.1.)
+
+2~ Verfahren
+
+# Die Entwickler befolgen das Standard-Beschlussverfahren – siehe weiter unten. Einen Beschluss oder Abänderung wird eingebracht, indem sie von irgendeinem Entwickler beantragt und von mindestens K anderen Entwicklern befürwortet wird, oder wenn sie vom Projektleiter oder Technischen Ausschuss beantragt wird.
+
+# Aufschieben einer Entscheidung des Projektleiters oder seines Delegierten:
+
+_# Wenn der Projektleiter, sein Delegierter oder der Technische Ausschuss eine Entscheidung getroffen hat, können Entwickler diese überstimmen, indem sie dazu einen Beschluss verabschieden; siehe §4.1(3).
+
+_# Wenn ein solcher Beschluss von wenigstens 2K Entwicklern befürwortet oder vom Technischen Ausschuss beantragt wird, vertagt der Beschluss die Entscheidung unmittelbar (vorausgesetzt, dieser Beschluss selbst besagt dies).
+
+_# Falls die ursprüngliche Entscheidung darin bestand, eine Diskussions- oder Abstimmungsfrist zu ändern, oder wenn der Beschluss darin besteht, den Technischen Ausschuss zu überstimmen, dann brauchen nur K Entwickler den Beschluss zu befürworten, um die Entscheidung unmittelbar vertagen zu können.
+
+_# Falls die Entscheidung vertagt wird, wird eine sofortige Abstimmung abgehalten, um zu bestimmen, ob die Entscheidung solange bestehen bleibt, bis die vollständige Abstimmung über die Entscheidung durchgeführt wurde, oder ob die Erfüllung der ursprünglichen Entscheidung bis dahin verzögert wird. Es gibt bei dieser unmittelbaren verfahrensbezogenen Abstimmung kein Quorum.
+
+_# Falls der Projektleiter (oder der Delegierte) die ursprüngliche Entscheidung zurückzieht, so wird die Abstimmung gegenstandslos und wird nicht weiter durchgeführt.
+
+# Der Projekt-Schriftführer lässt abstimmen. Stimmen, Stimmensummen und Ergebnisse werden während der Abstimmungsfrist nicht offen gelegt; nach der Abstimmung listet der Projekt-Schriftführer alle abgegebenen Stimmen auf. Die Abstimmungsfrist beträgt zwei Wochen, kann aber durch den Projektleiter um bis zu eine Woche variiert werden.
+
+# Die Mindestfrist für Diskussionen beträgt zwei Wochen, kann aber durch den Projektleiter um bis zu eine Woche variiert werden. Die Stimme des Projektleiters gibt den Ausschlag. Es gibt ein Quorum von 3Q.
+
+# Anträge, Befürwortungen, Abänderungen, Aufrufe zur Abstimmung und andere formelle Handlungen werden auf einer für die Öffentlichkeit lesbaren Mailingliste bekanntgegeben, die von dem bzw. den Delegierten des Projekt-Leiters bestimmt wird; jeder Entwickler kann dort Beiträge abgeben.
+
+# Stimmen werden in einer für den Schriftführer geeigneten Weise durch E-Mail abgegeben. Der Schriftführer legt für jede Abstimmung fest, ob die Abstimmenden ihre Stimme ändern können.
+
+# Q ist die Hälfte der Quadratwurzel aus der Anzahl der gegenwärtigen Entwickler. K ist Q oder 5, je nachdem, welches davon kleiner ist. Q und K brauchen nicht ganze Zahlen sein und werden nicht gerundet.
+
+1~ Projektleiter
+
+2~ Befugnisse
+
+Der Projektleiter darf
+
+# Delegierte ernennen oder Entscheidungen an den Technischen Ausschuss delegieren.
+
+Der Leiter darf einen Bereich mit fortlaufender Verantwortung oder eine bestimmte Entscheidung festlegen und diese an einen anderen Entwickler oder den Technischen Ausschuss übergeben.
+
+Sobald eine bestimmte Entscheidung delegiert und getroffen wurde, darf der Projektleiter diese Delegierung nicht zurückziehen; jedoch darf er eine fortlaufende Delegierung eines bestimmten Verantwortungsbereichs zurückziehen.
+
+# Anderen Entwicklern Vollmacht erteilen.
+
+Der Projektleiter kann Erklärungen zur Unterstützung von Standpunkten oder von anderen Mitgliedern des Projekts abgeben, gebeten oder ungebeten; diese Erklärungen haben dann und nur dann Kraft, wenn der Projektleiter befugt wäre, die fragliche Entscheidung zu treffen.
+
+# Jede Entscheidung treffen, welche dringende Handlung erfordert.
+
+Dies gilt nicht für Entscheidungen, die nur durch einen Mangel an entsprechenden Maßnahmen allmählich dringend geworden sind, außer wenn es einen festen Stichtag gibt.
+
+# Jede Entscheidung treffen, für die niemand sonst Verantwortung trägt.
+
+# Entwürfe für Allgemeine Beschlüsse und Abänderungen einbringen.
+
+# Zusammen mit dem Technischen Ausschuss neue Mitglieder in den Ausschuss berufen. (Siehe §6.2.)
+
+# Sich einer ausschlaggebenden Stimme bedienen, wenn Entwickler abstimmen.
+
+Der Projektleiter hat auch eine normale Stimme bei solchen Abstimmungen.
+
+# Die Diskussionsfrist für Abstimmungen der Entwickler variieren (wie oben).
+
+# Diskussionen unter Entwicklern leiten.
+
+Der Projektleiter sollte versuchen, an Diskussionen unter den Entwicklern auf eine hilfreiche Weise teilzunehmen, die versucht, die Diskussion zu den vorhandenen Kernproblemen zu bringen. Der Projektleiter sollte nicht seine Leitungsposition benutzen, um seine eigenen persönlichen Ansichten zu befördern.
+
+# Zusammen mit SPI Entscheidungen treffen, die mit Debian in Beziehung stehendes, treuhänderisch verwaltetes Eigentum betreffen. (Siehe §9.1.)
+
+2~ Ernennung
+
+# Der Projektleiter wird von den Entwicklern gewählt.
+
+# Die Wahl beginnt neun Wochen, bevor das Amt der Leitung frei wird, oder (wenn es bereits zu spät ist) sofort.
+
+# In den darauf folgenden drei Wochen kann jeder Entwickler sich selbst als Kandidat für das Amt des Projektleiters nominieren.
+
+# Danach können für drei Wochen keine weiteren Kandidaten nominiert werden; Kandidaten sollten diese Zeit für die Wahlkampagne nutzen (um ihre Person und Positionen bekannt zu machen). Falls es am Ende der Nominierungsfrist keine Kandidaten gibt, so wird die Nominierung um weitere drei Wochen verlängert – falls nötig, wiederholt.
+
+# Die nächsten drei Wochen sind der Abstimmungszeitraum, in der Entwickler ihre Stimmen abgeben können. Stimmen bei Wahlen für das Amt des Projektleiters werden geheimgehalten, sogar nachdem die Abstimmung beendet ist.
+
+# Die Wahlmöglichkeiten auf dem Stimmzettel sind diejenigen Kandidaten, die sich selbst nominiert und die Kandidatur noch nicht zurückgezogen haben, und zusätzlich »Niemand von den Obigen«. Falls »Niemand von den Obigen« die Wahl gewinnt, so wird das Wahlverfahren wiederholt – viele Male, falls nötig.
+
+# Die Entscheidung wird nach der in §A.6 des Standard-Beschlussverfahrens bestimmten Methode getroffen. Das Quorum ist dasselbe wie für einen Allgemeinen Beschluss (§4.2), und die Vorgabe-Wahlmöglichkeit ist »Niemand von den Obigen«.
+
+# Der Projektleiter amtiert nach seiner Wahl ein Jahr lang.
+
+2~ Verfahren
+
+Der Projektleiter sollte versuchen, Entscheidungen zu treffen, die mit dem Meinungskonsens der Entwickler vereinbar sind.
+
+Sofern es praktikabel ist, sollte der Projektleiter sich informell um die Ansichten der Entwickler bemühen.
+
+Der Projektleiter sollte es vermeiden, seinen eigenen Standpunkt übermäßig zu betonen, wenn er in seiner Eigenschaft als Projektleiter Entscheidungen trifft.
+
+1~ Technischer Ausschuss
+
+2~ Befugnisse
+
+Der Technische Ausschuss darf
+
+# Über jede Angelegenheit entscheiden, die technische Grundsätze betrifft.
+
+Dies schließt die Inhalte der Handbücher für technische Richtlinien, Nachschlagematerial für Entwickler, Beispielpakete und das Verhalten nicht-experimenteller Paketbau-Werkzeuge ein. (In jedem dieser Fälle trifft jedoch der übliche Betreuer der entsprechenden Software oder Dokumentation anfänglich Entscheidungen; siehe §6.3.(5).)
+
+# Über jede technische Angelegenheit entscheiden, in der sich die Entscheidungsbefugnisse von Entwicklern überlappen.
+
+In Fällen, bei denen Entwickler technische Richtlinien oder Standpunkte erfüllen müssen, die miteinander vereinbar sind (zum Beispiel, wenn sie über die Priorität miteinander im Konflikt stehender Pakete oder über das Eigentum am Namen eines Befehls verschiedener Meinung sind; oder darüber, welches Paket für einen Fehler verantwortlich ist, bei dem beide Betreuer sich einig sind, dass er ein Fehler ist; oder darüber, wer der Betreuer eines Pakets sein sollte), kann der technische Ausschuss die Angelegenheit entscheiden.
+
+# Eine Entscheidung treffen, wenn er darum gebeten wird.
+
+Jede Person und jedes Organ kann eine eigene Entscheidung an den Technischen Ausschuss delegieren, oder von ihm Rat einholen.
+
+# Einen Entwickler überstimmen (benötigt eine 3:1-Mehrheit).
+
+Der Technische Ausschuss kann einen Entwickler darum bitten, einen bestimmten technischen Handlungsweg zu beschreiten, sogar wenn der Entwickler dies nicht wünscht; dazu wird eine 3:1-Mehrheit benötigt. Zum Beispiel kann der Ausschuss festlegen, dass eine Beanstandung, die vom Einsender eines Fehlerberichts erhoben wurde, gerechtfertigt ist, und dass die vom Einsender vorgeschlagene Lösung erfüllt werden sollte.
+
+# Rat anbieten.
+
+Der Technische Ausschuss kann seine Ansichten über jegliche Angelegenheit formell bekannt machen. Einzelne Mitglieder können natürlich informelle Erklärungen über ihre Ansichten und über die voraussichtlichen Ansichten des Ausschusses abgeben.
+
+# Zusammen mit dem Projektleiter neue Mitglieder in den Ausschuss berufen oder vorhandene Mitglieder abberufen. (Siehe §6.2.)
+
+# Den Vorsitzenden des Technischen Ausschusses ernennen.
+
+Der Vorsitzende wird vom Ausschuss aus seinen Mitgliedern gewählt. Alle Mitglieder des Ausschusses werden automatisch nominiert; der Ausschuss beginnt eine Woche vor dem Freiwerden des Amtes zu wählen (oder sofort, wenn es bereits zu spät ist). Die Mitglieder können durch öffentliche Akklamation (d.h. Zuruf) für jedes Mitglied des Ausschusses stimmen, inklusive ihrer selbst; es gibt keine Vorgabe-Wahlmöglichkeit. Die Abstimmung endet, wenn alle Mitglieder abgestimmt haben, oder wenn die Abstimmungsfrist abgelaufen ist. Das Ergebnis wird durch die in §A.6 des Standard-Beschlussverfahrens bestimmte Methode festgelegt.
+
+# Der Vorsitzende kann den Projektleiter zusammen mit dem Schriftführer vertreten.
+
+Wie in §7.1(2) detailliert beschrieben wird, können der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer zusammen den Projektleiter vertreten, falls es keinen Projektleiter gibt.
+
+2~ Zusammensetzung
+
+# Der Technische Ausschuss besteht aus bis zu 8 Entwicklern und sollte für gewöhnlich mindestens 4 Mitglieder haben.
+
+# Wenn es weniger als 8 Mitglieder gibt, kann der Technische Ausschuss dem Projektleiter ein oder mehrere neue Mitglieder empfehlen, der seinerseits (im Einzelfall) entscheiden kann, ob er sie ernennt oder nicht.
+
+# Wenn es 5 oder weniger Mitglieder gibt, kann der Technische Ausschuss ein oder mehrere Mitglieder ernennen, bis die Anzahl der Mitglieder 6 erreicht.
+
+# Wenn es für mindestens eine Woche 5 oder weniger Mitglieder gegeben hat, kann der Projektleiter ein oder mehrere neue Mitglieder ernennen, bis die Anzahl der Mitglieder 6 erreicht – dies in Abständen von mindestens einer Woche pro Ernennung.
+
+# Falls der Technische Ausschuss und der Projektleiter sich einig sind, können sie ein im Technischen Ausschuss vorhandenes Mitglied entfernen oder ersetzen.
+
+2~ Verfahren
+
+# Der Technische Ausschuss bedient sich des Standard-Beschlussverfahrens.
+
+Ein Beschlussentwurf oder eine Abänderung kann von jedem Mitglied des Technischen Ausschusses vorgeschlagen werden. Es gibt keine Mindestfrist für Diskussionen; die Abstimmungsfrist dauert bis zu einer Woche, oder bis über den Ausgang kein Zweifel mehr besteht. Mitglieder können ihre Stimmen ändern. Das Quorum beträgt 2.
+
+# Einzelheiten, die die Abstimmung betreffen.
+
+Der Vorsitzende hat eine ausschlaggebende Stimme. Wenn der Technische Ausschuss darüber abstimmt, ob ein Entwickler, der ebenfalls Mitglied des Ausschusses ist, überstimmt werden soll, so darf dieser Entwickler nicht abstimmen (es sei denn, er ist der Vorsitzende – in diesem Fall kann er nur seine ausschlaggebende Stimme benutzen).
+
+# Öffentliche Diskussion und Entscheidungsfindung.
+
+Diskussion, Beschlussentwürfe und Abänderungen, sowie Stimmen von Mitgliedern des Ausschusses werden auf der öffentlichen Diskussionsliste des Technischen Ausschusses veröffentlicht. Es gibt keinen gesonderten Schriftführer für den Ausschuss.
+
+# Vertraulichkeit der Ernennungen.
+
+Der Technische Ausschuss kann vertrauliche Diskussionen durch private E-Mail, eine private Mailingliste oder andere Mittel abhalten, um Ernennungen in den Ausschuss zu diskutieren. Jedoch müssen Abstimmungen über Ernennungen öffentlich sein.
+
+# Keine Entwurfsarbeit in Einzelheiten.
+
+Der Technische Ausschuss nimmt nicht am Entwurf neuer Vorschläge oder Richtlinien teil. Solche Entwurfsarbeit sollte von Einzelpersonen für sich oder zusammen durchgeführt werden und in gewöhnlichen Foren für technische Richtlinien und Entwürfe diskutiert werden.
+
+Der Technische Ausschuss beschränkt sich darauf, Kompromisse zwischen Lösungen und Entscheidungen, welche anderswo vorgeschlagen und hinreichend gründlich diskutiert worden sind, auszuwählen oder aufzunehmen.
+
+Einzelne Mitglieder des Technischen Ausschusses können selbstverständlich in eigener Sache an jedem Aspekt der Arbeit an Entwürfen und Richtlinien teilhaben.
+
+# Der Technische Ausschuss fasst Beschlüsse nur als letzten Ausweg.
+
+Der Technische Ausschuss trifft keine technische Entscheidung, solange nicht Anstrengungen, diese durch einen Konsens zu entscheiden, unternommen wurden und fehlgeschlagen sind, außer wenn er von der Person oder dem Organ, das normalerweise dafür verantwortlich ist, darum gebeten wurde, eine Entscheidung zu treffen.
+
+1~ Der Projekt-Schriftführer
+
+2~ Befugnisse
+
+Der Schriftführer
+
+# Lässt unter den Entwicklern abstimmen und bestimmt die Anzahl und Person der Entwickler, wann immer dies die Verfassung erfordert.
+
+# Kann zusammen mit dem Vorsitzenden des Technischen Ausschusses an die Stelle des Projektleiters treten.
+
+Wenn es keinen Projektleiter gibt, können der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer in gegenseitigem Einvernehmen Entscheidungen treffen, wenn sie dies als unumgänglich betrachten.
+
+# Über jegliche Streitigkeit urteilen, die die Auslegung der Verfassung betrifft.
+
+# Kann seine Befugnisse teilweise oder vollständig an jemand anderen übertragen oder eine solche Delegierung zu jeder Zeit zurücknehmen.
+
+2~ Ernennung
+
+Der Projekt-Schriftführer wird vom Projektleiter und dem gegenwärtigen Projekt-Schriftführer ernannt.
+
+Wenn der Projektleiter und der gegenwärtige Projekt-Schriftführer sich nicht auf eine neue Ernennung einigen können, müssen sie den Vorstand von SPI (siehe §9.1.) darum bitten, einen Schriftführer zu ernennen.
+
+Wenn es keinen Projekt-Schriftführer gibt, oder der gegenwärtige Projekt-Schriftführer nicht erreichbar ist und seine Vollmacht über eine Entscheidung nicht abgegeben hat, kann der Vorsitzende des Technischen Ausschusses als stellvertretender Schriftführer die Entscheidung treffen oder delegieren.
+
+Die Amtszeit des Projekt-Schriftführers beträgt 1 Jahr, nach dessen Ablauf dieser oder ein anderer Schriftführer (wieder-)ernannt werden muss.
+
+2~ Verfahren
+
+Der Projekt-Schriftführer sollte gerechte und vernünftige Entscheidungen treffen, die vorzugsweise mit dem Konsens der Entwickler vereinbar sind.
+
+Wenn der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer zusammen stellvertretend für einen abwesenden Projektleiter handeln, sollten sie nur wenn absolut notwendig Entscheidungen treffen, und nur, wenn diese vereinbar mit dem Konsens der Entwickler sind.
+
+1~ Die Delegierten des Projektleiters
+
+2~ Befugnisse
+
+Die Delegierten des Projektleiters
+
+# haben vom Projektleiter an sie delegierte Befugnisse;
+
+# dürfen gewisse Entscheidungen treffen, die der Leiter nicht auf direkte Weise treffen darf. Dazu gehört, Entwickler anzuerkennen oder zu verweisen, oder Personen zu Entwicklern zu bestimmen, die keine Pakete betreuen. Dies dient dazu, eine Konzentration von Macht, besonders eine über Mitgliedschaft von Entwicklern, in den Händen des Projektleiters zu verhindern.
+
+2~ Ernennung
+
+Die Delegierten werden durch den Projektleiter ernannt und können vom Projektleiter nach seinem Ermessen ersetzt werden. Der Projektleiter kann weder die Position des Delegierten von bestimmten Entscheidungen des Delegierten abhängig machen, noch kann er sich über eine Entscheidung hinwegsetzen, die einmal von einem Delegierten getroffen wurde.
+
+2~ Verfahren
+
+Delegierte können Entscheidungen treffen, wie sie es für richtig halten, jedoch sollten sie versuchen, gute technische Entscheidungen zu vollziehen und/oder dem Meinungskonsens zu folgen.
+
+1~ Software in the Public Interest (»Software im öffentlichen Interesse«)
+
+SPI und Debian sind getrennte Organisationen, welche einige Ziele miteinander teilen. Debian ist dankbar für die rechtliche Unterstützung, die SPI anbietet. Die Entwickler von Debian sind gegenwärtig Mitglieder von SPI auf Grund ihres Status als Entwickler.
+
+2~ Befugnis
+
+# SPI hat keine Befugnis, die Debians technische oder nicht-technische Entscheidungen betrifft, mit den Ausnahmen, dass keine Entscheidung durch Debian in Hinsicht auf irgendwelches von SPI verwaltetes Eigentum erfordern darf, dass SPI außerhalb seiner rechtlichen Befugnis handelt, und dass Debians Verfassung SPI gelegentlich als entscheidendes Organ letzter Instanz verwenden darf.
+
+# Debian beansprucht keine Befugnis über SPI außer der über die Verwendung gewissen Eigentums von SPI, wie weiter unten beschrieben wird. Dennoch können den Debian-Entwicklern innerhalb von SPI nach den Vorschriften von SPI Befugnisse erteilt werden.
+
+# Debian-Entwickler sind keine Vertreter oder Angestellte von SPI oder voneinander oder von innerhalb des Debian-Projekts mit Befugnis versehenen Personen. Eine Person, die als Entwickler handelt, tut dies als Einzelperson, im eigenen Namen.
+
+2~ Verwaltung von Eigentum für Zwecke, die mit Debian in Beziehung stehen
+
+Da Debian keine Befugnis hat, Geld oder Eigentum zu besitzen, müssen jegliche Spenden für das Debian-Projekt an SPI gemacht werden, das solche Angelegenheiten handhabt.
+
+SPI hat folgende Zusicherungen gemacht:
+
+# SPI besitzt für mit Debian in Beziehung stehende Zwecke Geld, Warenzeichen und anderes materielle und immaterielle Eigentum und handhabt andere Angelegenheiten.
+
+# Solches Eigentum wird für diese Zwecke, über die Debian und SPI entsprechend dieses Abschnitts entscheiden, treuhänderisch mit separater Rechenschaft verwaltet.
+
+# SPI wird kein für Debian treuhänderisch verwaltetes Eigentum veräußern oder verwenden, ohne dass eine Genehmigung durch Debian vorliegt. Diese kann vom Projektleiter oder durch Allgemeine Beschlüsse der Entwickler erteilt werden.
+
+# SPI wird in Betracht ziehen, treuhänderisch verwaltetes Eigentum zu verwenden oder zu veräußern, wenn es durch den Projektleiter darum gebeten wird.
+
+# SPI wird für Debian treuhänderisch verwaltetes Eigentum verwenden oder veräußern, wenn es durch einen Allgemeinen Beschluss der Entwickler darum gebeten wird, vorausgesetzt, dass dies mit der rechtlichen Befugnis von SPI verträglich ist.
+
+# SPI wird die Entwickler durch E-Mail auf einer Mailingliste des Debian-Projekts benachrichtigen, wenn es für Debian treuhänderisch verwaltetes Eigentum verwendet oder veräußert.
+
+1~a A. Standard-Beschlussverfahren
+
+Diese Vorschriften betreffen gemeinschaftliche Entscheidungsfindung durch Ausschüsse sowie direkte Abstimmungen, wie oben angegeben.
+
+2~a1 A.1. Beantragung
+
+Das formelle Verfahren beginnt, wenn ein Beschlussentwurf beantragt und befürwortet wird, je nach Bedarf.
+
+2~a1a A.1. Diskussion und Abänderung
+
+# Nach der Beantragung kann der Beschluss diskutiert werden. Abänderungen können formell gemacht werden, indem sie entsprechend den Anforderungen an einen neuen Beschluss beantragt und befürwortet werden, oder auf direktem Wege durch den Antragsteller des ursprünglichen Beschlusses.
+
+# Eine formelle Abänderung kann durch den Antragsteller des Beschlusses angenommen werden. In diesem Fall wird der formelle Beschlussentwurf unmittelbar mit der Abänderung in Übereinstimmung gebracht.
+
+# Wenn eine formelle Abänderung nicht angenommen wird, oder einer der Befürworter des Beschlusses nicht mit der Annahme durch den Antragsteller einer formellen Abänderung einverstanden ist, bleibt die Abänderung eine Abänderung und es wird über sie abgestimmt.
+
+# Wenn eine vom ursprünglichen Antragsteller angenommene Abänderung nicht nach dem Geschmack Anderer ist, können diese eine weitere Abänderung einbringen, um die frühere Veränderung umzukehren (wieder müssen sie dann Antragsteller und Befürworter gemäß der Anforderungen sein).
+
+# Der Antragsteller eines Beschlusses kann Veränderungen an der Formulierung von Abänderungen vorschlagen; diese werden wirksam, wenn der Antragsteller der Abänderung damit einverstanden ist und keiner der Befürworter dagegen ist. In diesem Fall wird anstelle der ursprünglichen über die veränderten Abänderungen abgestimmt.
+
+# Der Antragsteller eines Beschlusses kann Veränderungen vornehmen, um unbedeutende Fehler (zum Beispiel Schreibfehler oder Ungereimtheiten) zu berichtigen, oder Veränderungen vornehmen, die nicht den Sinn ändern, vorausgesetzt niemand erhebt innerhalb von 24 Stunden Einwände. In diesem Fall beginnt die Mindestfrist für Diskussionen nicht von vorn.
+
+2~a2 A.2. Aufruf zur Abstimmung
+
+# Der Antragsteller oder ein Befürworter eines Antrages oder einer Abänderung kann zur Abstimmung aufrufen, vorausgesetzt, dass die Mindestfrist für Diskussionen (falls vorhanden) abgelaufen ist.
+
+# Der Antragsteller und jeder Befürworter eines Beschlusses können zu einer Abstimmung über diesen Beschluss und alle damit zusammenhängenden Abänderungen aufrufen.
+
+# Die Person, welche zu einer Abstimmung aufruft, gibt bekannt, welches ihrer Ansicht nach die Formulierung des Beschlusses und relevanter Abänderungen sind, und folglich, welche Form der Stimmzettel annehmen sollte. Dennoch liegt die endgültige Entscheidung über die Form des/der Stimmzettel beim Schriftführer – siehe §§7.1(1), 7.1(3) und A.3(4).
+
+# Die Mindestfrist für Diskussionen zählt ab dem Zeitpunkt, zu dem die letzte formelle Abänderung angenommen wurde, oder ab dem Zeitpunkt, zu dem der ganze Beschluss vorgeschlagen wurde, falls keine Abänderungen vorgeschlagen und angenommen wurden.
+
+2~a3 A.3. Wahlverfahren
+
+# Über jeden Beschluss und die damit zusammenhängenden Abänderungen wird auf einem einzigen Wahlzettel abgestimmt, der jeweils eine Wahlmöglichkeit für den ursprünglichen Beschluss, jede Abänderung und die Vorgabe-Wahlmöglichkeit (wo anwendbar) enthält.
+
+# Die Vorgabe-Wahlmöglichkeit darf keine Supermajorität erfordern. Wahlmöglichkeiten, die nicht explizit eine Supermajorität erfordern, erfordern eine 1:1-Mehrheit.
+
+# Die Stimmen werden nach den Vorschriften in §A.6. gezählt. Die Vorgabe-Wahlmöglichkeit heißt »Weitere Diskussion«, wenn nicht eine andere bestimmt wurde.
+
+# In Zweifelsfällen entscheidet der Projekt-Schriftführer über Angelegenheiten des Verfahrens.
+
+2~a4 A.4. Zurückziehen von Beschlüssen oder nicht angenommenen Abänderungen
+
+Der Antragsteller eines Beschlusses oder einer nicht angenommenen Abänderung kann diese zurückziehen. In diesem Fall können neue Antragsteller hervortreten, um sie am Leben zu halten; dann wiederum wird die erste Person, die dies tut, der neue Antragsteller, und alle anderen werden Befürworter, wenn sie dies nicht bereits sind.
+
+Ein Befürworter eines Beschlusses oder einer Abänderung (es sei denn, sie wurde angenommen) kann seine Befürwortung zurückziehen.
+
+Wenn die Zurückziehung durch den Antragsteller und/oder die Befürworter bedeutet, dass der Beschluss keinen Antragsteller oder nicht genug Befürworter hat, wird über sie nicht abgestimmt, es sei denn, dies wird berichtigt, bevor der Beschluss verfällt.
+
+2~a5 A.5. Verfall
+
+Wenn innerhalb von 4 Wochen ein vorgeschlagener Beschluss nicht diskutiert, nicht abgeändert, darüber abgestimmt oder auf andere Weise behandelt wurde, kann der Schriftführer eine Erklärung abgeben, dass man dabei ist, die Angelegenheit zurückzuziehen. Wenn keiner der Befürworter der Anträge innerhalb einer Woche Einwände erhebt, wird die Angelegenheit zurückgezogen.
+
+Der Schriftführer kann seiner Erklärung, falls angebracht, auch Vorschläge beifügen, wie man weiter vorgehen soll.
+
+2~a6 A.6. Stimmenzählung
+
+# Der Stimmzettel jedes Abstimmenden rangiert die Wahlmöglichkeiten (d.h.: ordnet ihnen einen Rang zu), über die abgestimmt wird. Nicht alle Wahlmöglichkeiten müssen rangiert werden. Rangierte Wahlmöglichkeiten werden als bevorzugt gegenüber allen nicht rangierten Wahlmöglichkeiten betrachtet. Die Abstimmenden können Wahlmöglichkeiten gleichrangig rangieren. Nicht rangierte Wahlmöglichkeiten werden als einander gleichrangig betrachtet. Einzelheiten darüber, wie Stimmzettel ausgefüllt werden können, werden mit in den »Aufruf zur Abstimmung« aufgenommen.
+
+# Falls der Wahlzettel ein Quorum R fordert, werden alle Wahlmöglichkeiten (außer der Vorgabe-Wahlmöglichkeit), die nicht mindestens R Stimmen erhalten, die diese Wahlmöglichkeit gegenüber der Vorgabe-Wahlmöglichkeit höher rangieren, fallen gelassen.
+
+# Jede (nicht-Vorgabe-) Wahlmöglichkeit, die die Vorgabe-Wahlmöglichkeit nicht mit ihrem benötigten Mehrheitsverhältnis überstimmt, wird fallengelassen.
+
+_# Sind zwei Wahlmöglichkeiten A und B gegeben, so ist V(A,B) die Anzahl der Abstimmenden, die Wahlmöglichkeit A gegenüber Wahlmöglichkeit B bevorzugen.
+
+_# Eine Wahlmöglichkeit A besiegt die Vorgabe-Wahlmöglichkeit D mit einem Mehrheitsverhältnis N, falls V(A,D) echt größer als N * V(D,A) ist.
+
+_# Wenn eine Supermajorität von S:1 für A benötigt wird, beträgt ihr Mehrheitsverhältnis S; im anderen Fall ist ihr Mehrheitsverhältnis 1.
+
+# Aus der Liste von nicht fallengelassenen Wahlmöglichkeiten erzeugen wir eine Liste von paarweisen Besiegungen.
+
+_# Eine Wahlmöglichkeit A besiegt eine Wahlmöglichkeit B, falls V(A,B) echt größer als V(B,A) ist.
+
+# Aus der Liste der paarweisen Besiegungen erzeugen wir eine Liste von transitiven Besiegungen.
+
+_# Eine Wahlmöglichkeit A besiegt eine Wahlmöglichkeit C transitiv, falls A C besiegt oder es eine andere Wahlmöglichkeit B gibt, so dass A B besiegt UND B transitiv C besiegt.
+
+# Wir konstruieren die Schwartzsche Menge aus der Menge der transitiven Besiegungen.
+
+_# Eine Wahlmöglichkeit A ist in der Schwartzschen Menge, falls für alle Wahlmöglichkeiten B entweder A transitiv B besiegt, oder B nicht transitiv A besiegt.
+
+# Wenn es Besiegungen zwischen Wahlmöglichkeiten gibt, die in der Schwartzschen Menge liegen, so lassen wir die schwächste solcher Besiegungen aus der Liste der paarweisen Besiegungen fallen und kehren zu Schritt 5 zurück.
+
+_# Eine Besiegung (A,X) ist schwächer als eine Besiegung (B,Y) falls V(A,X) kleiner als V(B,Y) ist. Außerdem ist (A,X) schwächer als (B,Y) falls V(A,X) gleich V(B,Y) ist, und V(X,A) größer als V(Y,B) ist.
+
+_# Eine schwächste Besiegung ist eine Besiegung, die keine andere schwächere Besiegung besitzt. Es kann mehr als eine solche Besiegung geben.
+
+# Falls es keine Besiegungen in der Schwartzschen Menge gibt, wird der Sieger aus den Wahlmöglichkeiten in der Schwartzschen Menge ausgewählt. Falls es nur eine solche Wahlmöglichkeit gibt, ist sie der Sieger. Falls es mehrere Wahlmöglichkeiten gibt, bestimmt der Stimmberechtigte mit der ausschlaggebenden Stimme, welche der Wahlmöglichkeiten siegt.
+
+Anmerkung: Wahlmöglichkeiten, welche die Abstimmenden über die Vorgabe-Wahlmöglichkeit rangieren, sind Wahlmöglichkeiten, die sie annehmbar finden. Unter die Vorgabe-Wahlmöglichkeit rangierte Wahlmöglichkeiten sind Wahlmöglichkeiten, die sie nicht annehmbar finden.
+
+Wenn das Standard-Beschlussverfahren benutzt werden soll, muss der darauf bezugnehmende Text bestimmen, was ausreicht, um einen Beschlussentwurf einzubringen und/oder zu befürworten, wie lange die Mindestfrist für Diskussionen dauert, und wie lange die Abstimmungsfrist dauert. Er muss auch jegliche Supermajorität und/oder das Quorum (und Vorgabe-Wahlmöglichkeit) bestimmen, die zu verwenden sind.
+
+1~b B. Sprachgebrauch und Typographie
+
+Der Präsens Indikativ (zum Beispiel »ist«) bedeutet, dass die Aussage eine Vorschrift in dieser Verfassung ist. »Darf« oder »kann« zeigt an, dass es im Ermessen der Person oder des Organs liegt. »Sollte« bedeutet, dass es als gute Sache betrachtet würde, wenn der Satz befolgt würde, aber er ist nicht bindend. Als Zitat markierter Text, so wie dieser, stellt nur Beweggründe dar, und bildet keinen Teil der Verfassung. Er darf nur dazu benutzt werden, um in Zweifelsfällen bei der Interpretation zu helfen.
+
+Anmerkung des Übersetzers: Obwohl diese Übersetzung mit Sorgfalt erstellt wurde, ist nur der englische Originaltext dieser Verfassung verbindlich.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/de/debian_constitution_v1.3.sst b/debian/data/doc/sisu/markup-samples/samples/v3/de/debian_constitution_v1.3.sst
new file mode 100644
index 00000000..4ff0812c
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/de/debian_constitution_v1.3.sst
@@ -0,0 +1,503 @@
+% SiSU 2.0
+
+% Zuletzt geändert: Mittwoch den 15. Nov 2006 um 22:29:40 Uhr UTC
+% Copyright © 1997-2006 SPI; Hier die Lizenzbestimmungen
+% Debian ist ein eingetragenes Warenzeichen von Software in the Public Interest, Inc.
+
+@title: Debian-Verfassung
+ :subtitle: Verfassung für das Debian-Projekt
+ :edition: v1.3
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution;language:German
+
+@date:
+ :published: 2003-10-29
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2006-09-24
+ :available: 2006-09-24
+ :modified: 2006-11-15
+
+@language:
+ :document: German
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.de.html <br> "Debian" und das Debian-Logo http://www.debian.org/logos/ sind Warenzeichen von Software in the Public Interest, Inc.
+ :license: Dieses Material darf nur unter den Bestimmungen, die in der Open Publication License, Draft v1.0 oder später (Sie können unsere lokale Kopie lesen http://www.debian.org/opl, die neuste Version ist normalerweise unter unter http://www.opencontent.org/openpub/ verfügbar) festgehalten sind, weitergegeben werden.
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Dies ist die am 24. September 2006 ratifizierte Version 1.3. Sie ersetzt die am 29. Oktober 2003 ratifizierte Version 1.2 und die am 21. Juni 2003 ratifizierte Version 1.1, welche ihrerseits die am 2. Dezember 1998 ratifizierte Version 1.0 ersetzt.<br> Dies ist die deutsche Übersetzung von "Debian's license" http://www.debian.org/license.en.html. In Zweifelsfällen ist das englische Original maßgeblich.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.3.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Debian-Verfassung
+
+:B~ Verfassung für das Debian-Projekt (v1.3)
+
+1~pre [Prefix]-#
+
+Dies ist die am 24. September 2006 ratifizierte { Version 1.3 }http://www.debian.org/devel/constitution.1.3. Sie ersetzt die am 29. Oktober 2003 ratifizierte { Version 1.2 }http://www.debian.org/devel/constitution.1.2 und die am 21. Juni 2003 ratifizierte { Version 1.1 }http://www.debian.org/devel/constitution.1.1, welche ihrerseits die am 2. Dezember 1998 ratifizierte { Version 1.0 }http://www.debian.org/devel/constitution.1.0 ersetzt.
+
+1~ Einleitung
+
+/{Das Debian-Projekt ist ein Verband von Einzelpersonen, die die Schaffung eines freien Betriebssystems zu ihrem gemeinsamen Anliegen gemacht haben.}/
+
+Dieses Dokument beschreibt die Organisationsstruktur für formelle Entscheidungsfindung innerhalb des Projekts. Es beschreibt nicht die Ziele des Projekts oder wie es diese erreicht, und es enthält keine Richtlinien außer denen, die sich direkt auf den Prozess der Entscheidungsfindung beziehen.
+
+2~ Entscheidungsfindende Organe und Einzelpersonen
+
+Jede Entscheidung innerhalb des Projekts wird von einem oder mehreren der folgenden Organe und Einzelpersonen getroffen:
+
+# Den Entwicklern, durch einen Allgemeinen Beschluss oder eine Wahl.
+
+# Dem Projektleiter;
+
+# Dem Technischen Ausschuss und/oder seinem Vorsitzenden;
+
+# Dem an einer einzelnen Aufgabe arbeitenden Entwickler;
+
+# Vom Projektleiter für bestimmte Aufgaben ernannten Delegierten;
+
+# Dem Projekt-Schriftführer.
+
+Das meiste vom Rest dieses Dokuments beschreibt die Befugnisse dieser Organe, ihre Zusammensetzung und Ernennung und das Verfahren bei ihrer Entscheidungsfindung. Die Befugnisse einer Person oder eines Organs können der Überwachung und/oder Einschränkung durch Andere unterworfen sein; in diesem Fall gibt dies der Eintrag des überwachenden Organs oder der Person an. In der obigen Liste ist eine Person oder ein Organ in der Regel vor irgendwelchen Personen oder Organen aufgeführt, deren Entscheidungen sie aufheben können oder die sie ernennen (oder ihnen dabei helfen) – jedoch kann nicht jeder, der vorher aufgeführt wird, jeden, der nachher aufgeführt wird, überstimmen.
+
+2~ Allgemeine Vorschriften
+
+# Nichts in dieser Verfassung erlegt irgendjemandem die Verpflichtung auf, für das Projekt Arbeit zu verrichten. Eine Person, die eine an sie delegierte oder ihr zugewiesene Aufgabe nicht erledigen möchte, muss es nicht tun. Jedoch darf sie nicht diesen Vorschriften oder Entscheidungen, die nach diesen Vorschriften ordnungsgemäß getroffen wurden, aktiv entgegenwirken.
+
+# Eine Person kann verschiedene Ämter innehaben, mit der Ausnahme, dass sich der Projektleiter, der Projekt-Schriftführer und der Vorsitzende des Technischen Ausschusses unterscheiden müssen, und dass der Projektleiter sich nicht zu seinem eigenen Delegierten ernennen kann.
+
+# Eine Person kann das Projekt verlassen oder ein bestimmtes Amt zu jeder Zeit niederlegen, indem sie dies öffentlich erklärt.
+
+1~ Einzelne Entwickler
+
+2~ Befugnisse
+
+Ein einzelner Entwickler darf
+
+# jede technische oder nicht-technische Entscheidung hinsichtlich seiner eigenen Arbeit treffen;
+
+# einen Entwurf zu einem Allgemeinen Beschluss einbringen oder befürworten;
+
+# sich bei Wahlen selbst als Kandidat für das Amt des Projektleiters vorschlagen;
+
+# bei Allgemeinen Beschlüssen und bei Wahlen über die Leitung abstimmen.
+
+2~ Zusammensetzung und Ernennung
+
+# Entwickler sind Freiwillige, die sich darin einig sind, die Ziele des Projekts insofern zu fördern, als sie an ihm teilhaben, und die ein oder mehrere Pakete für das Projekt betreuen oder andere Arbeit verrichten, welche der oder die Delegierten des Projektleiters als lohnenswert erachten.
+
+# Der oder die Delegierten des Projektleiters können es vorziehen, keine neuen Entwickler aufzunehmen, oder vorhandene Entwickler auszuschließen. Wenn die Entwickler verspüren, dass die Delegierten ihre Autorität missbrauchen, können sie selbstverständlich die Entscheidung durch einen Allgemeinen Beschluss außer Kraft setzen - siehe §4.1(3), §4.2.
+
+2~ Verfahren
+
+Entwickler können diese Entscheidungen treffen, wie sie es für richtig halten.
+
+1~ Die Entwickler durch einen Allgemeinen Beschluss oder Wahl
+
+2~ Befugnisse
+
+Zusammen können die Entwickler
+
+# Den Projektleiter ernennen oder abberufen.
+
+# Diese Verfassung abändern, vorausgesetzt, sie stimmen dem mit einer 3:1-Mehrheit zu.
+
+# Jede Entscheidung treffen oder außer Kraft setzen, zu der der Projektleiter oder einer seiner Delegierten befugt ist.
+
+# Jede Entscheidung treffen oder außer Kraft setzen, zu der der Technische Ausschuss befugt ist, vorausgesetzt sie stimmen diesem mit einer 2:1-Mehrheit zu.
+
+# Nicht-technische schriftliche Richtlinien und Erklärungen herausgeben, ersetzen und zurückziehen.
+
+Diese beinhalten Dokumente, welche die Ziele des Projekts und seine Beziehung zu anderen Gebilden der Freien Software beschreiben, sowie nicht-technische Richtlinien wie die Lizenzbedingungen für Freie Software, die Debian-Software erfüllen muss.
+
+Sie können auch Positionserklärungen zu Tagesfragen hinzufügen.
+
+_# Ein Gründungsdokument ist ein Dokument oder eine Erklärung, die als entscheidend für den Auftrag und die Zwecke des Projekts betrachtet werden.
+
+_# Die Gründungsdokumente sind die Arbeiten mit dem Titel Debian-Gesellschaftsvertrag und Debian Richtlinien für freie Software.
+
+_# Ein Gründungsdokument benötigt eine 3:1-Mehrheit, um ersetzt zu werden. Durch Abändern der Liste der Gründungsdokumente in dieser Verfassung werden neue Gründungsdokumente herausgegeben und vorhandene zurückgezogen.
+
+# Entscheidungen über treuhänderisch verwaltetes Eigentum treffen, welches mit den Zwecken von Debian in Beziehung steht. (Siehe §9.)
+
+# Im Falle einer Meinungsverschiedenheit zwischen dem Projektleiter und dem amtierenden Schriftführer einen neuen Schriftführer ernennen.
+
+2~ Verfahren
+
+# Die Entwickler befolgen das Standard-Beschlussverfahren – siehe weiter unten. Einen Beschluss oder Abänderung wird eingebracht, indem sie von irgendeinem Entwickler beantragt und von mindestens K anderen Entwicklern befürwortet wird, oder wenn sie vom Projektleiter oder Technischen Ausschuss beantragt wird.
+
+# Aufschieben einer Entscheidung des Projektleiters oder seines Delegierten:
+
+_# Wenn der Projektleiter, sein Delegierter oder der Technische Ausschuss eine Entscheidung getroffen hat, können Entwickler diese überstimmen, indem sie dazu einen Beschluss verabschieden; siehe §4.1(3).
+
+_# Wenn ein solcher Beschluss von wenigstens 2K Entwicklern befürwortet oder vom Technischen Ausschuss beantragt wird, vertagt der Beschluss die Entscheidung unmittelbar (vorausgesetzt, dieser Beschluss selbst besagt dies).
+
+_# Falls die ursprüngliche Entscheidung darin bestand, eine Diskussions- oder Abstimmungsfrist zu ändern, oder wenn der Beschluss darin besteht, den Technischen Ausschuss zu überstimmen, dann brauchen nur K Entwickler den Beschluss zu befürworten, um die Entscheidung unmittelbar vertagen zu können.
+
+_# Falls die Entscheidung vertagt wird, wird eine sofortige Abstimmung abgehalten, um zu bestimmen, ob die Entscheidung solange bestehen bleibt, bis die vollständige Abstimmung über die Entscheidung durchgeführt wurde, oder ob die Erfüllung der ursprünglichen Entscheidung bis dahin verzögert wird. Es gibt bei dieser unmittelbaren verfahrensbezogenen Abstimmung kein Quorum.
+
+_# Falls der Projektleiter (oder der Delegierte) die ursprüngliche Entscheidung zurückzieht, so wird die Abstimmung gegenstandslos und wird nicht weiter durchgeführt.
+
+# Der Projekt-Schriftführer lässt abstimmen. Stimmen, Stimmensummen und Ergebnisse werden während der Abstimmungsfrist nicht offen gelegt; nach der Abstimmung listet der Projekt-Schriftführer alle abgegebenen Stimmen auf. Die Abstimmungsfrist beträgt zwei Wochen, kann aber durch den Projektleiter um bis zu eine Woche variiert werden.
+
+# Die Mindestfrist für Diskussionen beträgt zwei Wochen, kann aber durch den Projektleiter um bis zu eine Woche variiert werden. Die Stimme des Projektleiters gibt den Ausschlag. Es gibt ein Quorum von 3Q.
+
+# Anträge, Befürwortungen, Abänderungen, Aufrufe zur Abstimmung und andere formelle Handlungen werden auf einer für die Öffentlichkeit lesbaren Mailingliste bekanntgegeben, die von dem bzw. den Delegierten des Projekt-Leiters bestimmt wird; jeder Entwickler kann dort Beiträge abgeben.
+
+# Stimmen werden in einer für den Schriftführer geeigneten Weise durch E-Mail abgegeben. Der Schriftführer legt für jede Abstimmung fest, ob die Abstimmenden ihre Stimme ändern können.
+
+# Q ist die Hälfte der Quadratwurzel aus der Anzahl der gegenwärtigen Entwickler. K ist Q oder 5, je nachdem, welches davon kleiner ist. Q und K brauchen nicht ganze Zahlen sein und werden nicht gerundet.
+
+1~ Projektleiter
+
+2~ Befugnisse
+
+Der Projektleiter darf
+
+# Delegierte ernennen oder Entscheidungen an den Technischen Ausschuss delegieren.
+
+Der Leiter darf einen Bereich mit fortlaufender Verantwortung oder eine bestimmte Entscheidung festlegen und diese an einen anderen Entwickler oder den Technischen Ausschuss übergeben.
+
+Sobald eine bestimmte Entscheidung delegiert und getroffen wurde, darf der Projektleiter diese Delegierung nicht zurückziehen; jedoch darf er eine fortlaufende Delegierung eines bestimmten Verantwortungsbereichs zurückziehen.
+
+# Anderen Entwicklern Vollmacht erteilen.
+
+Der Projektleiter kann Erklärungen zur Unterstützung von Standpunkten oder von anderen Mitgliedern des Projekts abgeben, gebeten oder ungebeten; diese Erklärungen haben dann und nur dann Kraft, wenn der Projektleiter befugt wäre, die fragliche Entscheidung zu treffen.
+
+# Jede Entscheidung treffen, welche dringende Handlung erfordert.
+
+Dies gilt nicht für Entscheidungen, die nur durch einen Mangel an entsprechenden Maßnahmen allmählich dringend geworden sind, außer wenn es einen festen Stichtag gibt.
+
+Jede Entscheidung treffen, für die niemand sonst Verantwortung trägt.
+
+# Entwürfe für Allgemeine Beschlüsse und Abänderungen einbringen.
+
+# Zusammen mit dem Technischen Ausschuss neue Mitglieder in den Ausschuss berufen. (Siehe §6.2.)
+
+# Sich einer ausschlaggebenden Stimme bedienen, wenn Entwickler abstimmen.
+
+Der Projektleiter hat auch eine normale Stimme bei solchen Abstimmungen.
+
+# Die Diskussionsfrist für Abstimmungen der Entwickler variieren (wie oben).
+
+# Diskussionen unter Entwicklern leiten.
+
+Der Projektleiter sollte versuchen, an Diskussionen unter den Entwicklern auf eine hilfreiche Weise teilzunehmen, die versucht, die Diskussion zu den vorhandenen Kernproblemen zu bringen. Der Projektleiter sollte nicht seine Leitungsposition benutzen, um seine eigenen persönlichen Ansichten zu befördern.
+
+# Im Einvernehmen mit den Entwicklern Entscheidungen fällen, die treuhänderisch verwaltetes Eigentum betreffen, welches mit den Zwecken von Debian in Beziehung steht. (Siehe §9.) Solche Entscheidungen werden den Mitgliedern durch den Projektleiter oder dessen Delegierte(n) mitgeteilt. Bedeutendere Ausgaben sollten beantragt und auf den Mailinglisten debattiert werden, bevor Gelder ausgezahlt werden.
+
+# Der Liste von vertrauenswürdigen Organisationen (siehe §9.3) Organisationen hinzufügen oder entfernen, die befugt sind, für Debian Vermögen anzunehmen und zu verwalten. Die zu einer solchen Entscheidung führende Beurteilung und Diskussion findet auf einer vom Projektleiter oder seines/seiner Delegierten bestimmten Mailingliste statt, auf der jeder Entwickler Beiträge abgeben kann. Es besteht eine Diskussionsfrist von mindestens zwei Wochen, bevor eine Organisation der Liste vertrauenswürdiger Organisationen hinzugefügt werden kann.
+
+2~ Ernennung
+
+# Der Projektleiter wird von den Entwicklern gewählt.
+
+# Die Wahl beginnt neun Wochen, bevor das Amt der Leitung frei wird, oder (wenn es bereits zu spät ist) sofort.
+
+# In den darauf folgenden drei Wochen kann jeder Entwickler sich selbst als Kandidat für das Amt des Projektleiters nominieren.
+
+# Danach können für drei Wochen keine weiteren Kandidaten nominiert werden; Kandidaten sollten diese Zeit für die Wahlkampagne nutzen (um ihre Person und Positionen bekannt zu machen). Falls es am Ende der Nominierungsfrist keine Kandidaten gibt, so wird die Nominierung um weitere drei Wochen verlängert – falls nötig, wiederholt.
+
+# Die nächsten drei Wochen sind der Abstimmungszeitraum, in der Entwickler ihre Stimmen abgeben können. Stimmen bei Wahlen für das Amt des Projektleiters werden geheimgehalten, sogar nachdem die Abstimmung beendet ist.
+
+# Die Wahlmöglichkeiten auf dem Stimmzettel sind diejenigen Kandidaten, die sich selbst nominiert und die Kandidatur noch nicht zurückgezogen haben, und zusätzlich Niemand von den Obigen. Falls Niemand von den Obigen die Wahl gewinnt, so wird das Wahlverfahren wiederholt – viele Male, falls nötig.
+
+# Die Entscheidung wird nach der in §A.6 des Standard-Beschlussverfahrens bestimmten Methode getroffen. Das Quorum ist dasselbe wie für einen Allgemeinen Beschluss (§4.2), und die Vorgabe-Wahlmöglichkeit ist Niemand von den Obigen.
+
+# Der Projektleiter amtiert nach seiner Wahl ein Jahr lang.
+
+2~ Verfahren
+
+Der Projektleiter sollte versuchen, Entscheidungen zu treffen, die mit dem Meinungskonsens der Entwickler vereinbar sind.
+
+Sofern es praktikabel ist, sollte der Projektleiter sich informell um die Ansichten der Entwickler bemühen.
+
+Der Projektleiter sollte es vermeiden, seinen eigenen Standpunkt übermäßig zu betonen, wenn er in seiner Eigenschaft als Projektleiter Entscheidungen trifft.
+
+1~ Technischer Ausschuss
+
+2~ Befugnisse
+
+Der Technische Ausschuss darf
+
+# Über jede Angelegenheit entscheiden, die technische Grundsätze betrifft.
+
+Dies schließt die Inhalte der Handbücher für technische Richtlinien, Nachschlagematerial für Entwickler, Beispielpakete und das Verhalten nicht-experimenteller Paketbau-Werkzeuge ein. (In jedem dieser Fälle trifft jedoch der übliche Betreuer der entsprechenden Software oder Dokumentation anfänglich Entscheidungen; siehe §6.3.(5).)
+
+# Über jede technische Angelegenheit entscheiden, in der sich die Entscheidungsbefugnisse von Entwicklern überlappen.
+
+In Fällen, bei denen Entwickler technische Richtlinien oder Standpunkte erfüllen müssen, die miteinander vereinbar sind (zum Beispiel, wenn sie über die Priorität miteinander im Konflikt stehender Pakete oder über das Eigentum am Namen eines Befehls verschiedener Meinung sind; oder darüber, welches Paket für einen Fehler verantwortlich ist, bei dem beide Betreuer sich einig sind, dass er ein Fehler ist; oder darüber, wer der Betreuer eines Pakets sein sollte), kann der technische Ausschuss die Angelegenheit entscheiden.
+
+# Eine Entscheidung treffen, wenn er darum gebeten wird.
+
+Jede Person und jedes Organ kann eine eigene Entscheidung an den Technischen Ausschuss delegieren, oder von ihm Rat einholen.
+
+# Einen Entwickler überstimmen (benötigt eine 3:1-Mehrheit).
+
+Der Technische Ausschuss kann einen Entwickler darum bitten, einen bestimmten technischen Handlungsweg zu beschreiten, sogar wenn der Entwickler dies nicht wünscht; dazu wird eine 3:1-Mehrheit benötigt. Zum Beispiel kann der Ausschuss festlegen, dass eine Beanstandung, die vom Einsender eines Fehlerberichts erhoben wurde, gerechtfertigt ist, und dass die vom Einsender vorgeschlagene Lösung erfüllt werden sollte.
+
+# Rat anbieten.
+
+Der Technische Ausschuss kann seine Ansichten über jegliche Angelegenheit formell bekannt machen. Einzelne Mitglieder können natürlich informelle Erklärungen über ihre Ansichten und über die voraussichtlichen Ansichten des Ausschusses abgeben.
+
+# Zusammen mit dem Projektleiter neue Mitglieder in den Ausschuss berufen oder vorhandene Mitglieder abberufen. (Siehe §6.2.)
+
+# Den Vorsitzenden des Technischen Ausschusses ernennen.
+
+Der Vorsitzende wird vom Ausschuss aus seinen Mitgliedern gewählt. Alle Mitglieder des Ausschusses werden automatisch nominiert; der Ausschuss beginnt eine Woche vor dem Freiwerden des Amtes zu wählen (oder sofort, wenn es bereits zu spät ist). Die Mitglieder können durch öffentliche Akklamation (d.h. Zuruf) für jedes Mitglied des Ausschusses stimmen, inklusive ihrer selbst; es gibt keine Vorgabe-Wahlmöglichkeit. Die Abstimmung endet, wenn alle Mitglieder abgestimmt haben, oder wenn die Abstimmungsfrist abgelaufen ist. Das Ergebnis wird durch die in §A.6 des Standard-Beschlussverfahrens bestimmte Methode festgelegt.
+
+# Der Vorsitzende kann den Projektleiter zusammen mit dem Schriftführer vertreten.
+
+Wie in §7.1(2) detailliert beschrieben wird, können der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer zusammen den Projektleiter vertreten, falls es keinen Projektleiter gibt.
+
+2~ Zusammensetzung
+
+# Der Technische Ausschuss besteht aus bis zu 8 Entwicklern und sollte für gewöhnlich mindestens 4 Mitglieder haben.
+
+# Wenn es weniger als 8 Mitglieder gibt, kann der Technische Ausschuss dem Projektleiter ein oder mehrere neue Mitglieder empfehlen, der seinerseits (im Einzelfall) entscheiden kann, ob er sie ernennt oder nicht.
+
+# Wenn es 5 oder weniger Mitglieder gibt, kann der Technische Ausschuss ein oder mehrere Mitglieder ernennen, bis die Anzahl der Mitglieder 6 erreicht.
+
+# Wenn es für mindestens eine Woche 5 oder weniger Mitglieder gegeben hat, kann der Projektleiter ein oder mehrere neue Mitglieder ernennen, bis die Anzahl der Mitglieder 6 erreicht – dies in Abständen von mindestens einer Woche pro Ernennung.
+
+# Falls der Technische Ausschuss und der Projektleiter sich einig sind, können sie ein im Technischen Ausschuss vorhandenes Mitglied entfernen oder ersetzen.
+
+2~ Verfahren
+
+# Der Technische Ausschuss bedient sich des Standard-Beschlussverfahrens.
+
+Ein Beschlussentwurf oder eine Abänderung kann von jedem Mitglied des Technischen Ausschusses vorgeschlagen werden. Es gibt keine Mindestfrist für Diskussionen; die Abstimmungsfrist dauert bis zu einer Woche, oder bis über den Ausgang kein Zweifel mehr besteht. Mitglieder können ihre Stimmen ändern. Das Quorum beträgt 2.
+
+# Einzelheiten, die die Abstimmung betreffen.
+
+Der Vorsitzende hat eine ausschlaggebende Stimme. Wenn der Technische Ausschuss darüber abstimmt, ob ein Entwickler, der ebenfalls Mitglied des Ausschusses ist, überstimmt werden soll, so darf dieser Entwickler nicht abstimmen (es sei denn, er ist der Vorsitzende – in diesem Fall kann er nur seine ausschlaggebende Stimme benutzen).
+
+# Öffentliche Diskussion und Entscheidungsfindung.
+
+Diskussion, Beschlussentwürfe und Abänderungen, sowie Stimmen von Mitgliedern des Ausschusses werden auf der öffentlichen Diskussionsliste des Technischen Ausschusses veröffentlicht. Es gibt keinen gesonderten Schriftführer für den Ausschuss.
+
+# Vertraulichkeit der Ernennungen.
+
+Der Technische Ausschuss kann vertrauliche Diskussionen durch private E-Mail, eine private Mailingliste oder andere Mittel abhalten, um Ernennungen in den Ausschuss zu diskutieren. Jedoch müssen Abstimmungen über Ernennungen öffentlich sein.
+
+# Keine Entwurfsarbeit in Einzelheiten.
+
+Der Technische Ausschuss nimmt nicht am Entwurf neuer Vorschläge oder Richtlinien teil. Solche Entwurfsarbeit sollte von Einzelpersonen für sich oder zusammen durchgeführt werden und in gewöhnlichen Foren für technische Richtlinien und Entwürfe diskutiert werden.
+
+Der Technische Ausschuss beschränkt sich darauf, Kompromisse zwischen Lösungen und Entscheidungen, welche anderswo vorgeschlagen und hinreichend gründlich diskutiert worden sind, auszuwählen oder aufzunehmen.
+
+Einzelne Mitglieder des Technischen Ausschusses können selbstverständlich in eigener Sache an jedem Aspekt der Arbeit an Entwürfen und Richtlinien teilhaben.
+
+# Der Technische Ausschuss fasst Beschlüsse nur als letzten Ausweg.
+
+Der Technische Ausschuss trifft keine technische Entscheidung, solange nicht Anstrengungen, diese durch einen Konsens zu entscheiden, unternommen wurden und fehlgeschlagen sind, außer wenn er von der Person oder dem Organ, das normalerweise dafür verantwortlich ist, darum gebeten wurde, eine Entscheidung zu treffen.
+
+1~ Der Projekt-Schriftführer
+
+2~ Befugnisse
+
+Der Schriftführer
+
+# Lässt unter den Entwicklern abstimmen und bestimmt die Anzahl und Person der Entwickler, wann immer dies die Verfassung erfordert.
+
+# Kann zusammen mit dem Vorsitzenden des Technischen Ausschusses an die Stelle des Projektleiters treten.
+
+Wenn es keinen Projektleiter gibt, können der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer in gegenseitigem Einvernehmen Entscheidungen treffen, wenn sie dies als unumgänglich betrachten.
+
+# Über jegliche Streitigkeit urteilen, die die Auslegung der Verfassung betrifft.
+
+# Kann seine Befugnisse teilweise oder vollständig an jemand anderen übertragen oder eine solche Delegierung zu jeder Zeit zurücknehmen.
+
+2~ Ernennung
+
+Der Projekt-Schriftführer wird vom Projektleiter und dem gegenwärtigen Projekt-Schriftführer ernannt.
+
+Wenn der Projektleiter und der gegenwärtige Projekt-Schriftführer sich nicht auf eine neue Ernennung einigen können, müssen sie die Entwickler auf dem Weg eines Allgemeinen Beschlusses darum bitten, einen Schriftführer zu ernennen.
+
+Wenn es keinen Projekt-Schriftführer gibt, oder der gegenwärtige Projekt-Schriftführer nicht erreichbar ist und seine Vollmacht über eine Entscheidung nicht abgegeben hat, kann der Vorsitzende des Technischen Ausschusses als stellvertretender Schriftführer die Entscheidung treffen oder delegieren.
+
+Die Amtszeit des Projekt-Schriftführers beträgt 1 Jahr, nach dessen Ablauf dieser oder ein anderer Schriftführer (wieder-)ernannt werden muss.
+
+2~ Verfahren
+
+Der Projekt-Schriftführer sollte gerechte und vernünftige Entscheidungen treffen, die vorzugsweise mit dem Konsens der Entwickler vereinbar sind.
+
+Wenn der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer zusammen stellvertretend für einen abwesenden Projektleiter handeln, sollten sie nur wenn absolut notwendig Entscheidungen treffen, und nur, wenn diese vereinbar mit dem Konsens der Entwickler sind.
+
+1~ Die Delegierten des Projektleiters
+
+2~ Befugnisse
+
+Die Delegierten des Projektleiters
+
+# haben vom Projektleiter an sie delegierte Befugnisse;
+
+# dürfen gewisse Entscheidungen treffen, die der Leiter nicht auf direkte Weise treffen darf. Dazu gehört, Entwickler anzuerkennen oder zu verweisen, oder Personen zu Entwicklern zu bestimmen, die keine Pakete betreuen. Dies dient dazu, eine Konzentration von Macht, besonders eine über Mitgliedschaft von Entwicklern, in den Händen des Projektleiters zu verhindern.
+
+2~ Ernennung
+
+Die Delegierten werden durch den Projektleiter ernannt und können vom Projektleiter nach seinem Ermessen ersetzt werden. Der Projektleiter kann weder die Position des Delegierten von bestimmten Entscheidungen des Delegierten abhängig machen, noch kann er sich über eine Entscheidung hinwegsetzen, die einmal von einem Delegierten getroffen wurde.
+
+2~ Verfahren
+
+Delegierte können Entscheidungen treffen, wie sie es für richtig halten, jedoch sollten sie versuchen, gute technische Entscheidungen zu vollziehen und/oder dem Meinungskonsens zu folgen.
+
+1~ Für Debian treuhänderisch verwaltetes Vermögen
+
+In den meisten Gerichtsbarkeiten auf der Welt ist Debian nicht in der Lage, direkt Vermögen oder anderes Eigentum zu besitzen. Daher muss Eigentum von einer Reihe von Organisationen besessen werden, wie in §9.2 genauer beschrieben wird.
+
+Traditionell war SPI die einzige Organisation, die befugt war, Eigentum und Gelder für das Debian-Projekt zu besitzen. SPI wurde in den Vereinigten Staaten gegründet, um dort Geld treuhänderisch zu verwalten.
+
+SPI und Debian sind getrennte Organisationen, welche einige Ziele miteinander teilen. Debian ist dankbar für die rechtliche Unterstützung, die SPI anbietet.
+
+2~ Beziehung zu angegliederten Organisationen
+
+# Debian-Entwickler werden nicht allein durch den Vorzug, Debian-Entwickler zu sein, Beauftragte oder Angestellte von für Debian treuhänderisch Vermögen verwaltenden Organisationen, oder voneinander, oder von Personen mit Befugnis im Debian-Projekt. Eine als Entwickler handelnde Person tut dies als Einzelperson, im eigenen Namen. Solche Organisationen dürfen jedoch aus eigenem Antrieb Beziehungen zu Einzelpersonen unterhalten, die auch Debian-Entwickler sind.
+
+2~ Befugnisse
+
+# Eine Organisation, welche für Debian Vermögen verwaltet, hat keine Befugnis hinsichtlich Debians technischer oder nichttechnischer Entscheidungen, außer, dass keine von Debians Entscheidungen bezüglich irgendwelchen von der Organisation verwalteten Eigentums von der Organisation verlangen möge, außerhalb ihrer rechtlichen Befugnis zu handeln.
+
+# Debian beansprucht keine Befugnis über eine Organisation, welche Vermögen für Debian verwaltet, außer der Benutzung des für Debian treuhänderisch verwalteten Eigentums.
+
+2~ 9.3. Vertrauenswürdige Organisationen
+
+Jegliche Spenden für das Debian-Projekt müssen an eine aus einer Reihe von Organisationen gehen, die vom Projektleiter (oder eines Delegierten) dazu ernannt wurden, für den Umgang mit für das Debian-Projekt verwendetem Vermögen befugt zu sein.
+
+Organisationen, die für Debian Vermögen treuhänderisch verwalten, sollten für den Umgang mit diesem Vermögen angemessene Verpflichtungen eingehen.
+
+Debian unterhält eine öffentliche Liste von vertrauenswürdigen Organisationen (List of Trusted Organisations), die Spenden annehmen und für Debian Vermögen treuhänderisch verwalten (hierbei sind sowohl Sachvermögen als auch geistiges Eigentum inbegriffen). Die Liste enthält sowohl die Verpflichtungen, die diese Organisationen eingehen, als auch wie mit diesem Vermögen umgegangen wird.
+
+1~a A. Standard-Beschlussverfahren
+
+Diese Vorschriften betreffen gemeinschaftliche Entscheidungsfindung durch Ausschüsse sowie direkte Abstimmungen, wie oben angegeben.
+
+2~a1 A.1. Beantragung
+
+Das formelle Verfahren beginnt, wenn ein Beschlussentwurf beantragt und befürwortet wird, je nach Bedarf.
+
+2~a1a A.1. Diskussion und Abänderung
+
+# Nach der Beantragung kann der Beschluss diskutiert werden. Abänderungen können formell gemacht werden, indem sie entsprechend den Anforderungen an einen neuen Beschluss beantragt und befürwortet werden, oder auf direktem Wege durch den Antragsteller des ursprünglichen Beschlusses.
+
+# Eine formelle Abänderung kann durch den Antragsteller des Beschlusses angenommen werden. In diesem Fall wird der formelle Beschlussentwurf unmittelbar mit der Abänderung in Übereinstimmung gebracht.
+
+# Wenn eine formelle Abänderung nicht angenommen wird, oder einer der Befürworter des Beschlusses nicht mit der Annahme durch den Antragsteller einer formellen Abänderung einverstanden ist, bleibt die Abänderung eine Abänderung und es wird über sie abgestimmt.
+
+# Wenn eine vom ursprünglichen Antragsteller angenommene Abänderung nicht nach dem Geschmack Anderer ist, können diese eine weitere Abänderung einbringen, um die frühere Veränderung umzukehren (wieder müssen sie dann Antragsteller und Befürworter gemäß der Anforderungen sein).
+
+# Der Antragsteller eines Beschlusses kann Veränderungen an der Formulierung von Abänderungen vorschlagen; diese werden wirksam, wenn der Antragsteller der Abänderung damit einverstanden ist und keiner der Befürworter dagegen ist. In diesem Fall wird anstelle der ursprünglichen über die veränderten Abänderungen abgestimmt.
+
+# Der Antragsteller eines Beschlusses kann Veränderungen vornehmen, um unbedeutende Fehler (zum Beispiel Schreibfehler oder Ungereimtheiten) zu berichtigen, oder Veränderungen vornehmen, die nicht den Sinn ändern, vorausgesetzt niemand erhebt innerhalb von 24 Stunden Einwände. In diesem Fall beginnt die Mindestfrist für Diskussionen nicht von vorn.
+
+2~a2 A.2. Aufruf zur Abstimmung
+
+# Der Antragsteller oder ein Befürworter eines Antrages oder einer Abänderung kann zur Abstimmung aufrufen, vorausgesetzt, dass die Mindestfrist für Diskussionen (falls vorhanden) abgelaufen ist.
+
+# Der Antragsteller und jeder Befürworter eines Beschlusses können zu einer Abstimmung über diesen Beschluss und alle damit zusammenhängenden Abänderungen aufrufen.
+
+# Die Person, welche zu einer Abstimmung aufruft, gibt bekannt, welches ihrer Ansicht nach die Formulierung des Beschlusses und relevanter Abänderungen sind, und folglich, welche Form der Stimmzettel annehmen sollte. Dennoch liegt die endgültige Entscheidung über die Form des/der Stimmzettel beim Schriftführer – siehe §§7.1(1), 7.1(3) und A.3(4).
+
+# Die Mindestfrist für Diskussionen zählt ab dem Zeitpunkt, zu dem die letzte formelle Abänderung angenommen wurde, oder ab dem Zeitpunkt, zu dem der ganze Beschluss vorgeschlagen wurde, falls keine Abänderungen vorgeschlagen und angenommen wurden.
+
+2~a3 A.3. Wahlverfahren
+
+# Über jeden Beschluss und die damit zusammenhängenden Abänderungen wird auf einem einzigen Wahlzettel abgestimmt, der jeweils eine Wahlmöglichkeit für den ursprünglichen Beschluss, jede Abänderung und die Vorgabe-Wahlmöglichkeit (wo anwendbar) enthält.
+
+# Die Vorgabe-Wahlmöglichkeit darf keine Supermajorität erfordern. Wahlmöglichkeiten, die nicht explizit eine Supermajorität erfordern, erfordern eine 1:1-Mehrheit.
+
+# Die Stimmen werden nach den Vorschriften in §A.6. gezählt. Die Vorgabe-Wahlmöglichkeit heißt Weitere Diskussion, wenn nicht eine andere bestimmt wurde.
+
+# In Zweifelsfällen entscheidet der Projekt-Schriftführer über Angelegenheiten des Verfahrens.
+
+2~a4 A.4. Zurückziehen von Beschlüssen oder nicht angenommenen Abänderungen
+
+Der Antragsteller eines Beschlusses oder einer nicht angenommenen Abänderung kann diese zurückziehen. In diesem Fall können neue Antragsteller hervortreten, um sie am Leben zu halten; dann wiederum wird die erste Person, die dies tut, der neue Antragsteller, und alle anderen werden Befürworter, wenn sie dies nicht bereits sind.
+
+Ein Befürworter eines Beschlusses oder einer Abänderung (es sei denn, sie wurde angenommen) kann seine Befürwortung zurückziehen.
+
+Wenn die Zurückziehung durch den Antragsteller und/oder die Befürworter bedeutet, dass der Beschluss keinen Antragsteller oder nicht genug Befürworter hat, wird über sie nicht abgestimmt, es sei denn, dies wird berichtigt, bevor der Beschluss verfällt.
+
+2~a5 A.5. Verfall
+
+Wenn innerhalb von 4 Wochen ein vorgeschlagener Beschluss nicht diskutiert, nicht abgeändert, darüber abgestimmt oder auf andere Weise behandelt wurde, kann der Schriftführer eine Erklärung abgeben, dass man dabei ist, die Angelegenheit zurückzuziehen. Wenn keiner der Befürworter der Anträge innerhalb einer Woche Einwände erhebt, wird die Angelegenheit zurückgezogen.
+
+Der Schriftführer kann seiner Erklärung, falls angebracht, auch Vorschläge beifügen, wie man weiter vorgehen soll.
+
+2~a6 A.6. Stimmenzählung
+
+# Der Stimmzettel jedes Abstimmenden rangiert die Wahlmöglichkeiten (d.h.: ordnet ihnen einen Rang zu), über die abgestimmt wird. Nicht alle Wahlmöglichkeiten müssen rangiert werden. Rangierte Wahlmöglichkeiten werden als bevorzugt gegenüber allen nicht rangierten Wahlmöglichkeiten betrachtet. Die Abstimmenden können Wahlmöglichkeiten gleichrangig rangieren. Nicht rangierte Wahlmöglichkeiten werden als einander gleichrangig betrachtet. Einzelheiten darüber, wie Stimmzettel ausgefüllt werden können, werden mit in den Aufruf zur Abstimmung aufgenommen.
+
+# Falls der Wahlzettel ein Quorum R fordert, werden alle Wahlmöglichkeiten (außer der Vorgabe-Wahlmöglichkeit), die nicht mindestens R Stimmen erhalten, die diese Wahlmöglichkeit gegenüber der Vorgabe-Wahlmöglichkeit höher rangieren, fallen gelassen.
+
+# Jede (nicht-Vorgabe-) Wahlmöglichkeit, die die Vorgabe-Wahlmöglichkeit nicht mit ihrem benötigten Mehrheitsverhältnis überstimmt, wird fallengelassen.
+
+_# Sind zwei Wahlmöglichkeiten A und B gegeben, so ist V(A,B) die Anzahl der Abstimmenden, die Wahlmöglichkeit A gegenüber Wahlmöglichkeit B bevorzugen.
+
+_# Eine Wahlmöglichkeit A besiegt die Vorgabe-Wahlmöglichkeit D mit einem Mehrheitsverhältnis N, falls V(A,D) echt größer als N * V(D,A) ist.
+
+_# Wenn eine Supermajorität von S:1 für A benötigt wird, beträgt ihr Mehrheitsverhältnis S; im anderen Fall ist ihr Mehrheitsverhältnis 1.
+
+# Aus der Liste von nicht fallengelassenen Wahlmöglichkeiten erzeugen wir eine Liste von paarweisen Besiegungen.
+
+_# Eine Wahlmöglichkeit A besiegt eine Wahlmöglichkeit B, falls V(A,B) echt größer als V(B,A) ist.
+
+# Aus der Liste der paarweisen Besiegungen erzeugen wir eine Liste von transitiven Besiegungen.
+
+_# Eine Wahlmöglichkeit A besiegt eine Wahlmöglichkeit C transitiv, falls A C besiegt oder es eine andere Wahlmöglichkeit B gibt, so dass A B besiegt UND B transitiv C besiegt.
+
+# Wir konstruieren die Schwartzsche Menge aus der Menge der transitiven Besiegungen.
+
+_# Eine Wahlmöglichkeit A ist in der Schwartzschen Menge, falls für alle Wahlmöglichkeiten B entweder A transitiv B besiegt, oder B nicht transitiv A besiegt.
+
+# Wenn es Besiegungen zwischen Wahlmöglichkeiten gibt, die in der Schwartzschen Menge liegen, so lassen wir die schwächste solcher Besiegungen aus der Liste der paarweisen Besiegungen fallen und kehren zu Schritt 5 zurück.
+
+_# Eine Besiegung (A,X) ist schwächer als eine Besiegung (B,Y) falls V(A,X) kleiner als V(B,Y) ist. Außerdem ist (A,X) schwächer als (B,Y) falls V(A,X) gleich V(B,Y) ist, und V(X,A) größer als V(Y,B) ist.
+
+_# Eine schwächste Besiegung ist eine Besiegung, die keine andere schwächere Besiegung besitzt. Es kann mehr als eine solche Besiegung geben.
+
+# Falls es keine Besiegungen in der Schwartzschen Menge gibt, wird der Sieger aus den Wahlmöglichkeiten in der Schwartzschen Menge ausgewählt. Falls es nur eine solche Wahlmöglichkeit gibt, ist sie der Sieger. Falls es mehrere Wahlmöglichkeiten gibt, bestimmt der Stimmberechtigte mit der ausschlaggebenden Stimme, welche der Wahlmöglichkeiten siegt.
+
+Anmerkung: Wahlmöglichkeiten, welche die Abstimmenden über die Vorgabe-Wahlmöglichkeit rangieren, sind Wahlmöglichkeiten, die sie annehmbar finden. Unter die Vorgabe-Wahlmöglichkeit rangierte Wahlmöglichkeiten sind Wahlmöglichkeiten, die sie nicht annehmbar finden.
+
+Wenn das Standard-Beschlussverfahren benutzt werden soll, muss der darauf bezugnehmende Text bestimmen, was ausreicht, um einen Beschlussentwurf einzubringen und/oder zu befürworten, wie lange die Mindestfrist für Diskussionen dauert, und wie lange die Abstimmungsfrist dauert. Er muss auch jegliche Supermajorität und/oder das Quorum (und Vorgabe-Wahlmöglichkeit) bestimmen, die zu verwenden sind.
+
+1~b B. Sprachgebrauch und Typographie
+
+Der Präsens Indikativ (zum Beispiel ist) bedeutet, dass die Aussage eine Vorschrift in dieser Verfassung ist. Darf oder kann zeigt an, dass es im Ermessen der Person oder des Organs liegt. Sollte bedeutet, dass es als gute Sache betrachtet würde, wenn der Satz befolgt würde, aber er ist nicht bindend. Als Zitat markierter Text, so wie dieser, stellt nur Beweggründe dar, und bildet keinen Teil der Verfassung. Er darf nur dazu benutzt werden, um in Zweifelsfällen bei der Interpretation zu helfen.
+
+Anmerkung des Übersetzers: Obwohl diese Übersetzung mit Sorgfalt erstellt wurde, ist nur der englische Originaltext dieser Verfassung verbindlich.
+
+
+
+% Dies ist die am 24. September 2006 ratifizierte
+% Version 1.3. Sie ersetzt die am 29. Oktober 2003
+% ratifizierte Version 1.2 und die am 21. Juni 2003
+% ratifizierte Version 1.1, welche ihrerseits die am
+% 2. Dezember 1998 ratifizierte Version 1.0 ersetzt.
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/de/debian_social_contract_v1.1.sst b/debian/data/doc/sisu/markup-samples/samples/v3/de/debian_social_contract_v1.1.sst
new file mode 100644
index 00000000..c0db5758
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/de/debian_social_contract_v1.1.sst
@@ -0,0 +1,139 @@
+% SiSU 2.0
+
+@title: Debian-Gesellschaftsvertrag
+ :subtitle: Debian Social Contract
+ :edition: v1.1
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:policy:social contract;GNU/Linux:debian:social contract;language:German
+
+@date:
+ :published: 2004-04-26
+ :created: 1997-07-05
+ :issued: 1997-07-05
+ :valid: 2004-04-26
+ :available: 2004-04-26
+ :modified: 2004-04-26
+
+@language:
+ :document: German
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.de.html <br>Dieses Material darf nur unter den Bestimmungen, die in der Open Publication License, Draft v1.0 oder später (Sie können unsere lokale Kopie lesen http://www.debian.org/opl, die neuste Version ist normalerweise unter unter http://www.opencontent.org/openpub/ verfügbar) festgehalten sind, weitergegeben werden. <br>Dies ist die deutsche Übersetzung von "Debian's license" http://www.debian.org/license.en.html. In Zweifelsfällen ist das englische Original maßgeblich.
+ :license: "Debian" und das Debian-Logo http://www.debian.org/logos/ sind Warenzeichen von Software in the Public Interest, Inc.
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/social_contract
+ {Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
+
+@make:
+ :breaks: new=C; break=1
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Debian-Gesellschaftsvertrag
+
+1~pre [Prefix]-#
+
+Dies ist die am 26. April 2004 ratifizierte Version 1.1. Sie ersetzt die am 5. Juli 1997 ratifizierte Version 1.0.
+
+Debian, die Hersteller des Systems Debian GNU/Linux, haben den »Gesellschaftsvertrag« aufgestellt. Die Debian-Richtlinien für Freie Software (DFSG), Teil dieses Vertrages und ursprünglich als eine Menge an Verpflichtungen entwickelt, denen wir zustimmen, wurden von der Free-Software-Community als Basis der Open-Source-Definition übernommen.
+
+1~ »Gesellschaftsvertrag« mit der Gemeinschaft für Freie Software
+
+2~ 1. Debian wird zu 100% frei bleiben
+
+Wir geben die Richtlinien, die wir verwenden, um zu bestimmen ob eine Arbeit »frei« ist, in dem »Die Debian-Richtlinien für Freie Software« genannten Dokument an. Wir versprechen, dass das Debian-System und alle dessen Komponenten entsprechend diesen Richtlinien frei sein werden. Wir werden Personen unterstützen, die freie und unfreie Arbeiten zu Debian erzeugen oder verwenden. Wir werden niemals das System von nicht-freien Komponenten abhängig machen.
+
+2~ 2. Unser Beitrag zur Gemeinschaft für Freie Software
+
+Wenn wir neue Komponenten des Debian-Systems schreiben, so werden wir sie auf eine Art lizenzieren, die in Einklang mit den Debian-Richtlinien für Freie Software steht. Wir werden das uns bestmögliche System erstellen, so dass Freie Arbeiten weit verbreitet und genutzt werden. Wir werden Dinge wie Korrekturen, Verbesserungen und Anwenderwünsche an die ursprünglichen (»upstream«) Autoren weiterleiten, deren Arbeiten in unser System integriert wurden.
+
+2~ 3. Wir werden Probleme nicht verbergen
+
+Wir werden unsere Fehlerdatenbank für alle Zeiten öffentlich betreiben. Fehlermeldungen, die von Personen online abgeschickt werden, werden unverzüglich für andere sichtbar.
+
+2~ 4. Unsere Prioritäten sind unsere Anwender und Freie Software
+
+Wir orientieren uns an den Bedürfnissen unserer Anwender und der Gemeinschaft für Freie Software. Deren Interessen stehen an erster Stelle. Wir werden unsere Nutzer bei ihrer Arbeit mit den verschiedensten Rechnerumgebungen unterstützen. Wir haben nichts gegen unfreie Arbeiten die darauf abzielen, auf Debian-Systemen verwendet zu werden, oder versuchen eine Gebühr von Personen, die solche Arbeiten erstellen oder verwenden, einzufordern. Wir erlauben anderen, Distributionen zu erstellen, die das Debian-System und andere Arbeiten enthalten, ohne dafür irgendwelche Gebühren zu erheben. Um diese Ziele zu fördern, werden wir ein integriertes System von hoher Qualität anbieten, das die gerade beschriebene Nutzung nicht durch rechtliche Einschränkungen verhindert.
+
+2~ 5. Arbeiten, die nicht unseren Standards für Freie Software genügen
+
+Wir wissen, dass einige unserer Anwender unbedingt Arbeiten einsetzen müssen, die nicht den Debian-Richtlinien für Freie Software entsprechen. Für solche Arbeiten haben wir die Bereiche »contrib« und »non-free« in unserem Archiv eingerichtet. Die Pakete in diesen Bereichen sind nicht Bestandteil des Debian-Systems, wurden aber trotzdem für den Einsatz mit Debian vorbereitet. Wir empfehlen den CD-Herstellern, die jeweiligen Lizenzbestimmungen der Pakete in diesen Bereichen zu studieren und selbst zu entscheiden, ob sie die Pakete mit ihren CDs verteilen dürfen. Obwohl unfreie Arbeiten nicht Bestandteil von Debian sind, unterstützen wir ihren Einsatz und bieten Infrastruktur für nicht freie Pakete an (z.B. unsere Fehlerdatenbank und die Mailinglisten).
+
+1~ Die Debian-Richtlinien für Freie Software (DFSG)
+
+2~ 1. Unbeschränkte Weitergabe
+
+Ein Bestandteil der Debian-Distribution darf durch seine Lizenz nicht verhindern, dass irgendjemand diese Software als Bestandteil einer Software-Distribution, die Programme aus den verschiedensten Quellen enthält, verkauft oder weitergibt. Die Lizenz darf keine Abgaben oder sonstige Leistungen für einen solchen Verkauf fordern.
+
+2~ 2. Quellcode
+
+Das Programm muss im Quellcode vorliegen, und es muss die Weitergabe sowohl im Quellcode als auch in kompilierter Form erlaubt sein.
+
+2~ 3. Weiterführende Arbeiten
+
+Die Lizenz muss Veränderungen und weiterführende Arbeiten gestatten und es erlauben, dass diese unter den gleichen Lizenzbedingungen weitergegeben werden dürfen wie die Original-Software.
+
+2~ 4. Integrität des ursprünglichen Quellcodes
+
+Die Lizenz darf die Weitergabe von verändertem Quellcode nur dann verbieten, wenn sie die Weitergabe von so genannten Patch-Dateien mit dem Quellcode erlaubt, die dazu dienen, das Programm vor seiner Herstellung zu modifizieren. Die Lizenz muss ausdrücklich die Weitergabe der aus dem veränderten Quellcode erzeugten Programme erlauben. Die Lizenz darf fordern, dass die veränderten Programme einen anderen Namen oder eine andere Versionsnummer tragen müssen. (Dies ist ein Kompromiss. Die Debian-Gruppe ermutigt alle Autoren, Veränderungen an Dateien sowohl im Quellcode als auch in Binärform zu erlauben.)
+
+2~ 5. Keine Diskriminierung von Personen oder Gruppen
+
+Die Lizenz darf keine Person oder Gruppe von Personen diskriminieren.
+
+2~ 6. Keine Diskriminierung von Einsatzbereichen
+
+Die Lizenz darf keine Einschränkungen hinsichtlich des Einsatzbereichs vornehmen. Beispielsweise darf sie nicht verhindern, dass das Programm geschäftlich oder für genetische Forschungen verwendet wird.
+
+2~ 7. Weitergabe der Lizenz
+
+Die mit einem Programm verbundenen Rechte müssen für alle gelten, die das Programm erhalten, ohne dass es für sie notwendig ist, eine zusätzliche Lizenz zu erwerben.
+
+2~ 8. Keine spezielle Lizenz für Debian
+
+Die mit dem Programm verbundenen Rechte dürfen nicht davon abhängig sein, dass das Programm Teil des Debian-Systems ist. Falls das Programm aus der Debian-Distribution herausgenommen wird und ohne Debian genutzt oder vertrieben werden soll, ansonsten aber im Rahmen der Programmlizenz bleibt, so müssen alle Parteien, die das Programm bekommen, die gleichen Rechte haben, wie sie im Zusammenhang mit dem Debian-System gewährt wurden.
+
+2~ 9. Keine Auswirkungen auf andere Programme
+
+Die Lizenz darf keine Beschränkungen besitzen, die Auswirkungen auf andere Software hat, die mit diesem Programm weitergegeben wird. Beispielsweise darf die Lizenz nicht vorschreiben, dass alle anderen Programme auf dem gleichen Medium Freie Software sein müssen.
+
+2~ 10. Beispiellizenzen
+
+Die »GPL«, »BSD« und »Artistic« Lizenzen sind Beispiele für Lizenzen, die wir als »frei« betrachten.
+
+Das Konzept, unseren »Gesellschaftsvertrag mit der Gemeinschaft für freie Software« aufzustellen, wurde von Ean Schuessler vorgeschlagen. Dieses Dokument wurde von Bruce Perens entworfen und von den anderen Debian-Entwicklern in einer einmonatigen E-Mail-Konferenz im Juni 1997 verfeinert, bevor es dann als öffentliche Richtlinie des Debian-Projekts akzeptiert wurde.
+
+Bruce Perens entfernte später die Debian-spezifischen Teile aus den Debian-Richtlinien für Freie Software um »Die Open-Source Definition« zu erstellen.
+
+Andere Organisationen können von diesem Dokument ableiten oder auf ihm aufbauen. Bitte erwähnen Sie das Debian-Projekt als Quelle, wenn Sie dies tun.
+
+Dies ist die deutsche Übersetzung von »Debian's social contract with the free software community«. In Zweifelsfällen ist das englische Original maßgeblich.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/en/debian_constitution_v1.2.adjusted.sst b/debian/data/doc/sisu/markup-samples/samples/v3/en/debian_constitution_v1.2.adjusted.sst
new file mode 100644
index 00000000..c67e267d
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/en/debian_constitution_v1.2.adjusted.sst
@@ -0,0 +1,502 @@
+% SiSU 2.0
+
+@title: Debian Constitution
+ :subtitle: Constitution for the Debian Project (v1.2) [This Document has been Superseded by v1.3]
+
+@creator:
+ :author: Debian Project
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license <br>"Debian" and the Debian Logo http://www.debian.org/logos/ are trademarks of Software in the Public Interest, Inc.
+ :license: This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy, the latest version is usually available at http://www.opencontent.org/openpub/).
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution
+
+@date:
+ :published: 2003-10-29
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2003-10-29
+ :available: 2003-10-29
+ :modified: 2003-10-29
+
+@language:
+ :document: English
+ :original: English
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {Debian Project}http://www.debian.org/
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Site map}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+ {License}http://www.debian.org/license
+
+@notes:
+ :prefix: This Document is Superseded by Version 1.3.<br>This version 1.2 was taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up as a SiSU sample document.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+:A~ Debian Constitution
+
+:B~ Constitution for the Debian Project (v1.2) [This Document has been Superseded by v1.3]
+
+1~pre [Prefix]-#
+
+Version 1.2 ratified on October 29th, 2003. Supersedes {Version 1.1}http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes {Version 1.0}http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.
+
+1~ 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.
+
+1~ 2. Decision-making bodies and individuals
+
+Each decision in the Project is made by one or more of the following:
+
+_1 1. The Developers, by way of General Resolution or an election;
+
+_1 2. The Project Leader;
+
+_1 3. The Technical Committee and/or its Chairman;
+
+_1 4. The individual Developer working on a particular task;
+
+_1 5. Delegates appointed by the Project Leader for specific tasks;
+
+_1 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~ 2.1 General rules
+
+_1 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.
+
+_1 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.
+
+_1 3. A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly.
+
+1~ 3 Individual Developers
+
+2~ 3.1 Powers
+
+An individual Developer may
+
+_1 1. make any technical or nontechnical decision with regard to their own work;
+
+_1 2. propose or sponsor draft General Resolutions;
+
+_1 3. propose themselves as a Project Leader candidate in elections;
+
+_1 4. vote on General Resolutions and in Leadership elections.
+
+2~ 3.2 Composition and appointment
+
+_1 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.
+
+_1 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.}/
+
+2~ 3.3 Procedure
+
+Developers may make these decisions as they see fit.
+
+1~ 4. The Developers by way of General Resolution or election
+
+2~ 4.1 Powers
+
+Together, the Developers may:
+
+_1 1. Appoint or recall the Project Leader.
+
+_1 2. Amend this constitution, provided they agree with a 3:1 majority.
+
+_1 3. Override any decision by the Project Leader or a Delegate.
+
+_1 4. Override any decision by the Technical Committee, provided they agree with a 2:1 majority.
+
+_1 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.
+
+_2 1. A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes.
+
+_2 2. The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines.
+
+_2 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.
+
+_1 6. Together with the Project Leader and SPI, make decisions about property held in trust for purposes related to Debian. (See §9.1.)
+
+2~ 4.2 Procedure
+
+_1 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.
+
+_1 2. Delaying a decision by the Project Leader or their Delegate:
+
+_2 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 s4.1(3).
+
+_2 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).
+
+_2 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.
+
+_2 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.
+
+_2 5. If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+1~ 5. Project Leader
+
+2~ 5.1 Powers
+
+The {Project Leader}http://www.debian.org/devel/leader may:
+
+_1 1. Appoint Delegates or delegate decisions to the Technical Committee.
+
+_1 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.
+
+_1 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.
+
+_1 2. Lend authority to other Developers.
+
+_1 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.
+
+_1 3. Make any decision which requires urgent action.
+
+_1 This does not apply to decisions which have only become gradually urgent through lack of relevant action, unless there is a fixed deadline.
+
+_1 4. Make any decision for whom noone else has responsibility.
+
+_1 5. Propose draft General Resolutions and amendments.
+
+_1 6. Together with the Technical Committee, appoint new members to the Committee. (See §6.2.)
+
+_1 7. Use a casting vote when Developers vote.
+
+_1 The Project Leader also has a normal vote in such ballots.
+
+_1 8. Vary the discussion period for Developers' votes (as above).
+
+_1 9. Lead discussions amongst Developers.
+
+_1 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.
+
+_1 10. Together with SPI, make decisions affecting property held in trust for purposes related to Debian. (See §9.1.)
+
+2~ 5.2 Appointment
+
+_1 1. The Project Leader is elected by the Developers.
+
+_1 2. The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately.
+
+_1 3. For the following three weeks any Developer may nominate themselves as a candidate Project Leader.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+_1 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".
+
+_1 8. The Project Leader serves for one year from their election.
+
+2~ 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.
+
+1~ 6. Technical committee
+
+2~ 6.1 Powers
+
+The {Technical Committee}http://www.debian.org/devel/tech-ctte may:
+
+_1 1. Decide on any matter of technical policy.
+
+_1 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).)
+
+_1 2. Decide any technical matter where Developers' jurisdictions overlap.
+
+_1 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.
+
+_1 3. Make a decision when asked to do so.
+
+_1 Any person or body may delegate a decision of their own to the Technical Committee, or seek advice from it.
+
+_1 4. Overrule a Developer (requires a 3:1 majority).
+
+_1 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.
+
+_1 5. Offer advice.
+
+_1 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.
+
+_1 6. Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.)
+
+_1 7. Appoint the Chairman of the Technical Committee.
+
+_1 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.
+
+_1 8. The Chairman can stand in for the Leader, together with the Secretary
+
+_1 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.
+
+2~ 6.2 Composition
+
+_1 1. The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members.
+
+_1 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.
+
+_1 3. When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6.
+
+_1 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.
+
+_1 5. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee.
+
+2~ 5.3 Procedure
+
+_1 1. The Technical Committee uses the Standard Resolution Procedure.
+
+_1 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.
+
+_1 2. Details regarding voting
+
+_1 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).
+
+_1 3. Public discussion and decision-making.
+
+_1 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.
+
+_1 4. Confidentiality of appointments.
+
+_1 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.
+
+_1 5. No detailed design work.
+
+_1 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.
+
+_1 The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere.
+
+_1 /{Individual members of the technical committee may of course participate on their own behalf in any aspect of design and policy work.}/
+
+_1 6. Technical Committee makes decisions only as last resort.
+
+_1 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.
+
+1~ 7. The Project Secretary
+
+2~ 7.1 Powers
+
+The {Secretary:}http://www.debian.org/devel/secretary
+
+_1 1. Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution.
+
+_1 2. Can stand in for the Leader, together with the Chairman of the Technical Committee.
+
+_1 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.
+
+_1 3. Adjudicates any disputes about interpretation of the constitution.
+
+_1 4. May delegate part or all of their authority to someone else, or withdraw such a delegation at any time.
+
+2~ 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.
+
+2~ 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.
+
+1~ 8. The Project Leader's Delegates
+
+2~ 8.1 Powers
+
+The Project Leader's Delegates:
+
+_1 1. have powers delegated to them by the Project Leader;
+
+_1 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.
+
+2~ 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.
+
+2~ 8.3 Procedure
+
+Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion.
+
+1~ 9. Software in the Public Interest
+
+{SPI}http://www.spi-inc.org/ 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.
+
+2~ 9.1 Authority
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+2~ 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 1. SPI will hold money, trademarks and other tangible and intangible property and manage other affairs for purposes related to Debian.
+
+_1 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.
+
+_1 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.
+
+_1 4. SPI will consider using or disposing of property held in trust for Debian when asked to do so by the Project Leader.
+
+_1 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.
+
+_1 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.
+
+1~a A. Standard Resolution Procedure
+
+These rules apply to communal decision-making by committees and plebiscites, where stated above.
+
+2~a1 A.1. Proposal
+
+The formal procedure begins when a draft resolution is proposed and sponsored, as required.
+
+2~a1a A.1 Discussion and Amendment
+
+_1 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.
+
+_1 2. A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match.
+
+_1 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.
+
+_1 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).)
+
+_1 5. The proposer or 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.
+
+_1 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.
+
+2~a2 A.2. Calling for a vote
+
+_1 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.
+
+_1 2. The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments.
+
+_1 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).
+
+_1 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.
+
+2~a3 A.3. Voting procedure
+
+_1 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).
+
+_1 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.
+
+_1 3. The votes are counted according to the rules in A.6. The default option is "Further Discussion", unless specified otherwise.
+
+_1 4. In cases of doubt the Project Secretary shall decide on matters of procedure.
+
+2~a4 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.
+
+2~a5 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.
+
+2~a6 A.6. Vote Counting
+
+_1 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.
+
+_1 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.
+
+_1 3. Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration.
+
+_2 1. Given two options A and B, V(A,B) is the number of voters who prefer option A over option B.
+
+_2 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).
+
+_2 3. If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1.
+
+_1 4. From the list of undropped options, we generate a list of pairwise defeats.
+
+_1 1. An option A defeats an option B, if V(A,B) is strictly greater than V(B,A).
+
+_1 5. From the list of [undropped] pairwise defeats, we generate a set of transitive defeats.
+
+_1 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.
+
+_1 6. We construct the Schwartz set from the set of transitive defeats.
+
+_2 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.
+
+_1 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.
+
+_2 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 2. A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat.
+
+_1 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.}/
+
+2~b 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.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/en/debian_constitution_v1.2.sst b/debian/data/doc/sisu/markup-samples/samples/v3/en/debian_constitution_v1.2.sst
new file mode 100644
index 00000000..c59067d3
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/en/debian_constitution_v1.2.sst
@@ -0,0 +1,499 @@
+% SiSU 2.0
+
+@title: Debian Constitution
+ :subtitle: Constitution for the Debian Project (v1.2) [This Document has been Superseded by v1.3]
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution
+
+@date:
+ :published: 2003-10-29
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2003-10-29
+ :available: 2003-10-29
+ :modified: 2003-10-29
+
+@language:
+ :document: English
+ :original: English
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license <br>"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc.
+ :license: This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+:A~ Debian Constitution
+
+:B~ Constitution for the Debian Project (v1.2) [This Document has been Superseded by v1.3]
+
+1~pre [Prefix]-#
+
+Version 1.2 ratified on October 29th, 2003. Supersedes {Version 1.1}http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes {Version 1.0}http://www.debian.org/devel/constitution.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.
+
+1~ Decision-making bodies and individuals
+
+Each decision in the Project is made by one or more of the following:
+
+# The Developers, by way of General Resolution or an election;
+
+# The Project Leader;
+
+# The Technical Committee and/or its Chairman;
+
+# The individual Developer working on a particular task;
+
+# Delegates appointed by the Project Leader for specific tasks;
+
+# 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~ General rules
+
+# 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.
+
+# 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.
+
+# A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly.
+
+1~ Individual Developers
+
+2~ Powers
+
+An individual Developer may
+
+# make any technical or nontechnical decision with regard to their own work;
+
+# propose or sponsor draft General Resolutions;
+
+# propose themselves as a Project Leader candidate in elections;
+
+# vote on General Resolutions and in Leadership elections.
+
+2~ Composition and appointment
+
+# 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.
+
+# 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.}/
+
+2~ Procedure
+
+Developers may make these decisions as they see fit.
+
+1~ The Developers by way of General Resolution or election
+
+2~ Powers
+
+Together, the Developers may:
+
+# Appoint or recall the Project Leader.
+
+# Amend this constitution, provided they agree with a 3:1 majority.
+
+# Override any decision by the Project Leader or a Delegate.
+
+# Override any decision by the Technical Committee, provided they agree with a 2:1 majority.
+
+# 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.
+
+_# A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes.
+
+_# The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines.
+
+_# 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.
+
+# Together with the Project Leader and SPI, make decisions about property held in trust for purposes related to Debian. (See §9.1.)
+
+2~ Procedure
+
+# 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.
+
+# Delaying a decision by the Project Leader or their Delegate:
+
+_# 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 s4.1(3).
+
+_# 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).
+
+_# 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.
+
+_# 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.
+
+_# If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted.
+
+# 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.
+
+# 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.
+
+# 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.
+
+# Votes are cast by email in a manner suitable to the Secretary. The Secretary determines for each poll whether voters can change their votes.
+
+# 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.
+
+1~ Project Leader
+
+2~ Powers
+
+The {Project Leader}http://www.debian.org/devel/leader may:
+
+# 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.
+
+# 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.
+
+# 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.
+
+# Make any decision for whom noone else has responsibility.
+
+# Propose draft General Resolutions and amendments.
+
+# Together with the Technical Committee, appoint new members to the Committee. (See §6.2.)
+
+# Use a casting vote when Developers vote.
+
+The Project Leader also has a normal vote in such ballots.
+
+# Vary the discussion period for Developers' votes (as above).
+
+# 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.
+
+# Together with SPI, make decisions affecting property held in trust for purposes related to Debian. (See §9.1.)
+
+2~ Appointment
+
+# The Project Leader is elected by the Developers.
+
+# The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately.
+
+# For the following three weeks any Developer may nominate themselves as a candidate Project Leader.
+
+# 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.
+
+# 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.
+
+# 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.
+
+# 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".
+
+# The Project Leader serves for one year from their election.
+
+2~ 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.
+
+1~ Technical committee
+
+2~ Powers
+
+The {Technical Committee}http://www.debian.org/devel/tech-ctte may:
+
+# 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).)
+
+# 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.
+
+# 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.
+
+# 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.
+
+# 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.
+
+# Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.)
+
+# 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.
+
+# 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.
+
+2~ Composition
+
+# The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members.
+
+# 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.
+
+# When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6.
+
+# 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.
+
+# If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee.
+
+2~ Procedure
+
+# 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.
+
+# 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).
+
+# 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.
+
+# 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.
+
+# 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.}/
+
+# 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.
+
+1~ The Project Secretary
+
+2~ Powers
+
+The {Secretary:}http://www.debian.org/devel/secretary
+
+# Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution.
+
+# 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.
+
+# Adjudicates any disputes about interpretation of the constitution.
+
+# May delegate part or all of their authority to someone else, or withdraw such a delegation at any time.
+
+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.
+
+2~ 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.
+
+1~ The Project Leader's Delegates
+
+2~ Powers
+
+The Project Leader's Delegates:
+
+# have powers delegated to them by the Project Leader;
+
+# 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.
+
+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.
+
+2~ Procedure
+
+Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion.
+
+1~ Software in the Public Interest
+
+{SPI}http://www.spi-inc.org/ 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.
+
+2~ Authority
+
+# 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.
+
+# 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.
+
+# 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.
+
+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:
+
+# SPI will hold money, trademarks and other tangible and intangible property and manage other affairs for purposes related to Debian.
+
+# Such property will be accounted for separately and held in trust for those purposes, decided on by Debian and SPI according to this section.
+
+# 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.
+
+# SPI will consider using or disposing of property held in trust for Debian when asked to do so by the Project Leader.
+
+# 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.
+
+# 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.
+
+1~a A. Standard Resolution Procedure
+
+These rules apply to communal decision-making by committees and plebiscites, where stated above.
+
+2~a1 A.1. Proposal
+
+The formal procedure begins when a draft resolution is proposed and sponsored, as required.
+
+2~a1a A.1 Discussion and Amendment
+
+# 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.
+
+# A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match.
+
+# 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.
+
+# 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).)
+
+# The proposer or 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.
+
+# 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.
+
+2~a2 A.2. Calling for a vote
+
+# 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.
+
+# The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments.
+
+# 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).
+
+# 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.
+
+2~a3 A.3. Voting procedure
+
+# 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).
+
+# The default option must not have any supermajority requirements. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement.
+
+# The votes are counted according to the rules in A.6. The default option is "Further Discussion", unless specified otherwise.
+
+# In cases of doubt the Project Secretary shall decide on matters of procedure.
+
+2~a4 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.
+
+2~a5 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.
+
+2~a6 A.6. Vote Counting
+
+# 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.
+
+# 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.
+
+# Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration.
+
+_# Given two options A and B, V(A,B) is the number of voters who prefer option A over option B.
+
+_# 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).
+
+_# If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1.
+
+# From the list of undropped options, we generate a list of pairwise defeats.
+
+_# An option A defeats an option B, if V(A,B) is strictly greater than V(B,A).
+
+# From the list of [undropped] pairwise defeats, we generate a set of transitive defeats.
+
+_# 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.
+
+# We construct the Schwartz set from the set of transitive defeats.
+
+_# 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.
+
+# 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.
+
+_# 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).
+
+_# A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat.
+
+# 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.}/
+
+1~b 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.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/en/debian_constitution_v1.3.adjusted.sst b/debian/data/doc/sisu/markup-samples/samples/v3/en/debian_constitution_v1.3.adjusted.sst
new file mode 100644
index 00000000..51a047b8
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/en/debian_constitution_v1.3.adjusted.sst
@@ -0,0 +1,506 @@
+% SiSU 2.0
+
+% Last Modified: Tue, Nov 14 15:39:52 UTC 2006
+% Copyright © 1997-2006 SPI; See license terms
+% Debian is a registered trademark of Software in the Public Interest, Inc.
+
+@title: Debian Constitution
+ :subtitle: Constitution for the Debian Project
+ :edition: v1.3
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution
+
+@date:
+ :published: 2006-09-24
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2006-09-24
+ :available: 2006-09-24
+ :modified: 2006-11-14
+
+@language:
+ :document: English
+ :original: English
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license <br>"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc.
+ :license: This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {Debian Project}http://www.debian.org/
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Site map}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up as a SiSU sample document.<br>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.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.3.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+:A~ Debian Constitution
+
+:B~ Constitution for the Debian Project (v1.3)
+
+1~pre [Prefix]-#
+
+{Version 1.3}http://www.debian.org/devel/constitution.1.3 ratified on September 24th, 2006. Supersedes {Version 1.2}http://www.debian.org/devel/constitution.1.2 ratified on October 29th, 2003 and {Version 1.1}http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes {Version 1.0}http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.
+
+1~ 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.
+
+1~ 2. Decision-making bodies and individuals
+
+Each decision in the Project is made by one or more of the following:
+
+_1 1. The Developers, by way of General Resolution or an election;
+
+_1 2. The Project Leader;
+
+_1 3. The Technical Committee and/or its Chairman;
+
+_1 4. The individual Developer working on a particular task;
+
+_1 5. Delegates appointed by the Project Leader for specific tasks;
+
+_1 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~ 2.1. General rules
+
+_1 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.
+
+_1 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.
+
+_1 3. A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly.
+
+1~ 3. Individual Developers
+
+2~ 3.1. Powers
+
+An individual Developer may
+
+_1 1. make any technical or nontechnical decision with regard to their own work;
+
+_1 2. propose or sponsor draft General Resolutions;
+
+_1 3. propose themselves as a Project Leader candidate in elections;
+
+_1 4. vote on General Resolutions and in Leadership elections.
+
+2~ 3.2. Composition and appointment
+
+_1 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.
+
+_1 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.
+
+2~ 3.3. Procedure
+
+Developers may make these decisions as they see fit.
+
+1~ 4. The Developers by way of General Resolution or election
+
+2~ 4.1. Powers
+
+Together, the Developers may:
+
+_1 1. Appoint or recall the Project Leader.
+
+_1 2. Amend this constitution, provided they agree with a 3:1 majority.
+
+_1 3. Make or override any decision authorised by the powers of the Project Leader or a Delegate.
+
+_1 4. Make or override any decision authorised by the powers of the Technical Committee, provided they agree with a 2:1 majority.
+
+_1 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.
+
+_2 1. A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes.
+
+_2 2. The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines.
+
+_2 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.
+
+_1 6. Make decisions about property held in trust for purposes related to Debian. (See §9.).
+
+_1 7. In case of a disagreement between the project leader and the incumbent secretary, appoint a new secretary.
+
+2~ 4.2. Procedure
+
+_1 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.
+
+_1 2. Delaying a decision by the Project Leader or their Delegate:
+
+_2 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 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).
+
+_2 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.
+
+_2 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.
+
+_2 5. If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+1~ 5. Project Leader
+
+2~ 5.1. Powers
+
+The {Project Leader}http://www.debian.org/devel/leader may:
+
+_1 1. Appoint Delegates or delegate decisions to the Technical Committee.
+
+_1 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.
+
+_1 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.
+
+_1 2. Lend authority to other Developers.
+
+_1 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.
+
+_1 3. Make any decision which requires urgent action.
+
+_1 This does not apply to decisions which have only become gradually urgent through lack of relevant action, unless there is a fixed deadline.
+
+_1 4. Make any decision for whom noone else has responsibility.
+
+_1 5. Propose draft General Resolutions and amendments.
+
+_1 6. Together with the Technical Committee, appoint new members to the Committee. (See §6.2.)
+
+_1 7. Use a casting vote when Developers vote.
+
+_1 The Project Leader also has a normal vote in such ballots.
+
+_1 8. Vary the discussion period for Developers' votes (as above).
+
+_1 9. Lead discussions amongst Developers.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+2~ 5.2. Appointment
+
+_1 1. The Project Leader is elected by the Developers.
+
+_1 2. The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately.
+
+_1 3. For the following three weeks any Developer may nominate themselves as a candidate Project Leader.
+
+_1 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.
+
+_1 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.
+
+_1 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.
+
+_1 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".
+
+_1 8. The Project Leader serves for one year from their election.
+
+2~ 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.
+
+1~ 6. Technical committee
+
+2~ 6.1. Powers
+
+The {Technical Committee}http://www.debian.org/devel/tech-ctte may:
+
+_1 1. Decide on any matter of technical policy.
+
+_1 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).)
+
+_1 2. Decide any technical matter where Developers' jurisdictions overlap.
+
+_1 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.
+
+_1 3. Make a decision when asked to do so.
+
+_1 Any person or body may delegate a decision of their own to the Technical Committee, or seek advice from it.
+
+_1 4. Overrule a Developer (requires a 3:1 majority).
+
+_1 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.
+
+_1 5. Offer advice.
+
+_1 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.
+
+_1 6. Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.)
+
+_1 7. Appoint the Chairman of the Technical Committee.
+
+_1 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.
+
+_1 8. The Chairman can stand in for the Leader, together with the Secretary
+
+_1 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.
+
+2~ 6.2. Composition
+
+_1 1. The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members.
+
+_1 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.
+
+_1 3. When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6.
+
+_1 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.
+
+_1 5. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee.
+
+2~ 6.3. Procedure
+
+_1 1. The Technical Committee uses the Standard Resolution Procedure.
+
+_1 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.
+
+_1 2. Details regarding voting
+
+_1 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).
+
+_1 3. Public discussion and decision-making.
+
+_1 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.
+
+_1 4. Confidentiality of appointments.
+
+_1 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.
+
+_1 5. No detailed design work.
+
+_1 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.
+
+_1 The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere.
+
+_1 Individual members of the technical committee may of course participate on their own behalf in any aspect of design and policy work.
+
+_1 6. Technical Committee makes decisions only as last resort.
+
+_1 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.
+
+1~ 7. The Project Secretary
+
+2~ 7.1. Powers
+
+The {Secretary:}http://www.debian.org/devel/secretary
+
+_1 1. Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution.
+
+_1 2. Can stand in for the Leader, together with the Chairman of the Technical Committee.
+
+_1 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.
+
+_1 3. Adjudicates any disputes about interpretation of the constitution.
+
+_1 4. May delegate part or all of their authority to someone else, or withdraw such a delegation at any time.
+
+2~ 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.
+
+2~ 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.
+
+1~ 8. The Project Leader's Delegates
+
+2~ 8.1. Powers
+
+The Project Leader's Delegates:
+
+_1 1. have powers delegated to them by the Project Leader;
+
+_1 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.
+
+2~ 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.
+
+2~ 8.3. Procedure
+
+Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion.
+
+1~ 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.
+
+2~ 9.1. Relationship with Associated Organizations
+
+_1 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.
+
+2~ 9.2. Authority
+
+_1 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.
+
+_1 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.
+
+2~ 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.
+
+1~a A. Standard Resolution Procedure
+
+These rules apply to communal decision-making by committees and plebiscites, where stated above.
+
+2~a1 A.1. Proposal
+
+The formal procedure begins when a draft resolution is proposed and sponsored, as required.
+
+2~a1a A.1. Discussion and Amendment
+
+_1 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.
+
+_1 2. A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match.
+
+_1 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.
+
+_1 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).)
+
+_1 5. The proposer or 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.
+
+_1 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.
+
+2~a2 A.2. Calling for a vote
+
+_1 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.
+
+_1 2. The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments.
+
+_1 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).
+
+_1 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.
+
+2~a3 A.3. Voting procedure
+
+_1 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).
+
+_1 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.
+
+_1 3. The votes are counted according to the rules in A.6. The default option is "Further Discussion", unless specified otherwise.
+
+_1 4. In cases of doubt the Project Secretary shall decide on matters of procedure.
+
+2~a4 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.
+
+2~a5 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.
+
+2~a6 A.6. Vote Counting
+
+_1 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.
+
+_1 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.
+
+_1 3. Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration.
+
+_2 1. Given two options A and B, V(A,B) is the number of voters who prefer option A over option B.
+
+_2 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).
+
+_2 3. If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1.
+
+_1 4. From the list of undropped options, we generate a list of pairwise defeats.
+
+_2 1. An option A defeats an option B, if V(A,B) is strictly greater than V(B,A).
+
+_1 5. From the list of [undropped] pairwise defeats, we generate a set of transitive defeats.
+
+_2 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.
+
+_1 6. We construct the Schwartz set from the set of transitive defeats.
+
+_2 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.
+
+_1 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.
+
+_2 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 2. A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat.
+
+_1 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. }/
+
+2~b 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.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/en/debian_constitution_v1.3.sst b/debian/data/doc/sisu/markup-samples/samples/v3/en/debian_constitution_v1.3.sst
new file mode 100644
index 00000000..fdf0d91e
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/en/debian_constitution_v1.3.sst
@@ -0,0 +1,507 @@
+% SiSU 2.0
+
+% Last Modified: Tue, Nov 14 15:39:52 UTC 2006
+% Copyright © 1997-2006 SPI; See license terms
+% Debian is a registered trademark of Software in the Public Interest, Inc.
+
+@title: Debian Constitution
+ :subtitle: Constitution for the Debian Project (v1.3)
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution
+
+@date:
+ :published: 2006-09-24
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2006-09-24
+ :available: 2006-09-24
+ :modified: 2006-11-14
+
+@language:
+ :document: English
+ :original: English
+
+% @italics:
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license <br>"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc.
+ :license: This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {Debian Project}http://www.debian.org/
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Site map}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up as a SiSU sample document.<br>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.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.3.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Debian Constitution
+
+:B~ Constitution for the Debian Project (v1.3)
+
+1~pre [Prefix]-#
+
+{Version 1.3}http://www.debian.org/devel/constitution.1.3 ratified on September 24th, 2006. Supersedes {Version 1.2}http://www.debian.org/devel/constitution.1.2 ratified on October 29th, 2003 and {Version 1.1}http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes {Version 1.0}http://www.debian.org/devel/constitution.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.
+
+1~ Decision-making bodies and individuals
+
+Each decision in the Project is made by one or more of the following:
+
+# The Developers, by way of General Resolution or an election;
+
+# The Project Leader;
+
+# The Technical Committee and/or its Chairman;
+
+# The individual Developer working on a particular task;
+
+# Delegates appointed by the Project Leader for specific tasks;
+
+# 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~ General rules
+
+# 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.
+
+# 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.
+
+# A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly.
+
+1~ Individual Developers
+
+2~ Powers
+
+An individual Developer may
+
+# make any technical or nontechnical decision with regard to their own work;
+
+# propose or sponsor draft General Resolutions;
+
+# propose themselves as a Project Leader candidate in elections;
+
+# vote on General Resolutions and in Leadership elections.
+
+2~ Composition and appointment
+
+# 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.
+
+# 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.
+
+2~ Procedure
+
+Developers may make these decisions as they see fit.
+
+1~ The Developers by way of General Resolution or election
+
+2~ Powers
+
+Together, the Developers may:
+
+# Appoint or recall the Project Leader.
+
+# Amend this constitution, provided they agree with a 3:1 majority.
+
+# Make or override any decision authorised by the powers of the Project Leader or a Delegate.
+
+# Make or override any decision authorised by the powers of the Technical Committee, provided they agree with a 2:1 majority.
+
+# 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.
+
+_# A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes.
+
+_# The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines.
+
+_# 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.
+
+# Make decisions about property held in trust for purposes related to Debian. (See §9.).
+
+# In case of a disagreement between the project leader and the incumbent secretary, appoint a new secretary.
+
+2~ Procedure
+
+# 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.
+
+# Delaying a decision by the Project Leader or their Delegate:
+
+_# 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).
+
+_# 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).
+
+_# 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.
+
+_# 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.
+
+_# If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted.
+
+# 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.
+
+# 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.
+
+# 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.
+
+# Votes are cast by email in a manner suitable to the Secretary. The Secretary determines for each poll whether voters can change their votes.
+
+# 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.
+
+1~ Project Leader
+
+2~ Powers
+
+The {Project Leader}http://www.debian.org/devel/leader may:
+
+# 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.
+
+# 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.
+
+# 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.
+
+# Make any decision for whom noone else has responsibility.
+
+# Propose draft General Resolutions and amendments.
+
+# Together with the Technical Committee, appoint new members to the Committee. (See §6.2.)
+
+# Use a casting vote when Developers vote.
+
+The Project Leader also has a normal vote in such ballots.
+
+# Vary the discussion period for Developers' votes (as above).
+
+# 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.
+
+# 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.
+
+# 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.
+
+2~ Appointment
+
+# The Project Leader is elected by the Developers.
+
+# The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately.
+
+# For the following three weeks any Developer may nominate themselves as a candidate Project Leader.
+
+# 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.
+
+# 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.
+
+# 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.
+
+# 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".
+
+# The Project Leader serves for one year from their election.
+
+2~ 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.
+
+1~ Technical committee
+
+2~ Powers
+
+The {Technical Committee}http://www.debian.org/devel/tech-ctte may:
+
+# 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).)
+
+# 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.
+
+# 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.
+
+# 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.
+
+# 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.
+
+# Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.)
+
+# 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.
+
+# 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.
+
+2~ Composition
+
+# The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members.
+
+# 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.
+
+# When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6.
+
+# 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.
+
+# If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee.
+
+2~ Procedure
+
+# 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.
+
+# 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).
+
+# 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.
+
+# 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.
+
+# 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.}/
+
+# 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.
+
+1~ The Project Secretary
+
+2~ Powers
+
+The {Secretary:}http://www.debian.org/devel/secretary
+
+# Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution.
+
+# 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.
+
+# Adjudicates any disputes about interpretation of the constitution.
+
+# May delegate part or all of their authority to someone else, or withdraw such a delegation at any time.
+
+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.
+
+2~ 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.
+
+1~ The Project Leader's Delegates
+
+2~ Powers
+
+The Project Leader's Delegates:
+
+# have powers delegated to them by the Project Leader;
+
+# 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.
+
+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.
+
+2~ Procedure
+
+Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion.
+
+1~ 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.
+
+2~ Relationship with Associated Organizations
+
+# 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.
+
+2~ Authority
+
+# 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.
+
+# 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.
+
+2~ 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.
+
+1~a A. Standard Resolution Procedure
+
+These rules apply to communal decision-making by committees and plebiscites, where stated above.
+
+2~a1 A.1. Proposal
+
+The formal procedure begins when a draft resolution is proposed and sponsored, as required.
+
+2~a1a A.1 Discussion and Amendment
+
+# 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.
+
+# A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match.
+
+# 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.
+
+# 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).)
+
+# The proposer or 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.
+
+# 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.
+
+2~a2 A.2. Calling for a vote
+
+# 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.
+
+# The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments.
+
+# 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).
+
+# 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.
+
+2~a3 A.3. Voting procedure
+
+# 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).
+
+# The default option must not have any supermajority requirements. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement.
+
+# The votes are counted according to the rules in A.6. The default option is "Further Discussion", unless specified otherwise.
+
+# In cases of doubt the Project Secretary shall decide on matters of procedure.
+
+2~a4 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.
+
+2~a5 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.
+
+2~a6 A.6. Vote Counting
+
+# 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.
+
+# 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.
+
+# Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration.
+
+_# Given two options A and B, V(A,B) is the number of voters who prefer option A over option B.
+
+_# 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).
+
+_# If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1.
+
+# From the list of undropped options, we generate a list of pairwise defeats.
+
+_# An option A defeats an option B, if V(A,B) is strictly greater than V(B,A).
+
+# From the list of [undropped] pairwise defeats, we generate a set of transitive defeats.
+
+_# 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.
+
+# We construct the Schwartz set from the set of transitive defeats.
+
+_# 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.
+
+# 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.
+
+_# 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).
+
+_# A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat.
+
+# 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.}/
+
+1~b 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.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/en/debian_social_contract_v1.1.sst b/debian/data/doc/sisu/markup-samples/samples/v3/en/debian_social_contract_v1.1.sst
new file mode 100644
index 00000000..2add6ea9
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/en/debian_social_contract_v1.1.sst
@@ -0,0 +1,136 @@
+% SiSU 2.0
+
+@title: Debian Social Contract
+ :subtitle: (v1.1)
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:policy:social contract;GNU/Linux:debian:social contract
+
+@date:
+ :published: 2004-04-26
+ :created: 1997-07-05
+ :issued: 1997-07-05
+ :valid: 2004-04-26
+ :available: 2004-04-26
+ :modified: 2004-04-26
+
+@language:
+ :document: English
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license <br>"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc.
+ :license: This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/social_contract
+ {Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
+
+@make:
+ :breaks: new=C; break=1
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Debian Social Contract
+
+1~pre [Prefix]-#
+
+Version 1.1 ratified on April 26, 2004. Supersedes {Version 1.0}http://www.debian.org/social_contract.1.0 ratified on July 5, 1997.
+
+Debian, the producers of the Debian GNU/Linux system, have created the *{Debian Social Contract}*. The {Debian Free Software Guidelines (DFSG)}http://www.debian.org/social_contract#guidelines 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.}http://www.opensource.org/docs/definition_plain.html
+
+1~ Social Contract with the Free Software Community
+
+2~ 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~ 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.
+
+2~ 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.
+
+2~ 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.
+
+2~ 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).
+
+1~ The Debian Free Software Guidelines (DFSG)
+
+2~ 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~ 2. Source Code
+
+The program must include source code, and must allow distribution in source code as well as compiled form.
+
+2~ 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.
+
+2~ 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.)
+
+2~ 5. No Discrimination Against Persons or Groups
+
+The license must not discriminate against any person or group of persons.
+
+2~ 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.
+
+2~ 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.
+
+2~ 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.
+
+2~ 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.
+
+2~ 10. Example Licenses
+
+The {"GPL"}http://www.debian.org/social_contract.1.0, {"BSD"}http://www.debian.org/misc/bsd.license, and {"Artistic"}http://www.perl.com/pub/a/language/misc/Artistic.html 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}http://lists.debian.org/debian-announce/debian-announce-1997/msg00017.html 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".}http://www.opensource.org/docs/definition.php }/
+
+/{Other organizations may derive from and build on this document. Please give credit to the Debian project if you do.}/
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/es/debian_constitution_v1.2.sst b/debian/data/doc/sisu/markup-samples/samples/v3/es/debian_constitution_v1.2.sst
new file mode 100644
index 00000000..e64c4d63
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/es/debian_constitution_v1.2.sst
@@ -0,0 +1,517 @@
+% SiSU 2.0
+
+@title: Constitución de Debian
+ :subtitle: Constitución del Proyecto Debian
+ :edition: v1.2
+ :note: [This Document has been Superseded by v1.3]
+
+@creator:
+ :author: Debian Project
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, http://www.spi-inc.org/ Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.es.html <br>"Debian" y el logotipo de Debian http://www.debian.org/logos/ son marcas registradas de Software in the Public Interest, Inc.
+ :license: OJO: Esta es una traducción de la licencia original, y no tiene ningún valor jurídico http://www.debian.org/license.en.html. Si desea ver la versión verdadera debe acudir a la licencia original, en este mismo servidor.<br>Este material sólo puede ser distribuido sujeto a los términos y condiciones indicados en la Licencia de publicaciones abiertas, borrador v1.0 o posterior (puede consultar nuestra copia local http://www.debian.org/opl ; la última versión suele estar disponible en http://www.opencontent.org/openpub/ ).
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution;language:Spanish
+
+@date:
+ :published: 2003-10-29
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2003-10-29
+ :available: 2003-10-29
+ :modified: 2006-11-14
+
+% Última modificación: mar, 14 de nov de 2006, 15:44:29 UTC
+
+@language:
+ :document: Spanish
+ :original: English
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2.default/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+:A~ Constitución de Debian
+
+:B~ Constitución del Proyecto Debian (v1.2) [This Document has been Superseded by v1.3]
+
+1~pre [Prefix]-#
+
+Versión 1.2 ratificada el 29 de octubre de 2003. Sustituye a la versión 1.1 ratificada el 21 de junio de 2003, que a su vez sustituía a la versión 1.0 ratificada el 2 de diciembre de 1998.
+
+1~ 1. Introducción
+
+El Proyecto Debian es una asociación de individuos que han hecho causa común para crear un sistema operativo libre.
+
+Este documento describe la estructura organizativa para la toma de decisiones en el Proyecto. No describe las metas del Proyecto o cómo alcanzarlas, ni contiene ninguna norma excepto aquellas relacionadas directamente con el proceso de toma de decisiones.
+
+1~ 2. Individuos y organismos de toma de decisiones
+
+Cada decisión en el Proyecto la toman uno o más de los siguientes:
+
+# Los Desarrolladores, mediante una Resolución General o una elección;
+
+# El Líder del Proyecto;
+
+# El Comité Técnico o su Presidente (chairman);
+
+# El Desarrollador que trabaja en una tarea determinada;
+
+# Delegados nombrados por el Líder del Proyecto para tareas específicas;
+
+# El Secretario del Proyecto.
+
+La mayoría del resto de este documento le ayudará a formar una idea de las atribuciones de estos organismos, su composición y nombramientos, y el proceso de toma de decisiones. Las atribuciones de una persona u organismo pueden estar sujetos a revisión y/o limitación por parte de terceros; en ese caso el organismo o personas encargadas de la revisión indicarán dicha posibilidad. En la lista anterior, normalmente se lista a una persona u organismo antes de aquellos cuyas decisiones puede anular o a los que escoge (o ayuda a escoger); pero no todos los que se nombran al principio mandan sobre todos los posteriores.
+
+2~ Reglas generales
+
+# Nada en esta constitución impone obligaciones a nadie que trabaje para el Proyecto. Una persona que no quiera hacer la tarea que le ha sido delegada o asignada no necesita hacerla. Sin embargo, no se debe actuar activamente en contra de estas reglas y las decisiones tomadas apropiadamente siguiéndolas.
+
+# Una persona puede ocupar varios puestos, pero el Líder del Proyecto, el Secretario del Proyecto y el Presidente del Comité Técnico deben ser personas distintas, además de que el Líder no puede elegirlos como sus Delegados.
+
+# Una persona puede abandonar el Proyecto o dimitir de un cargo en particular, en cualquier momento, diciéndolo públicamente.
+
+1~ Desarrolladores individuales
+
+2~ Atribuciones
+
+Un Desarrollador puede
+
+# tomar una decisión técnica o no técnica con respecto a su propio trabajo;
+
+# proponer o patrocinar borradores de Resoluciones Generales;
+
+# proponerse a sí mismos como candidatos a Líder del Proyecto durante las elecciones;
+
+# votar en una Resolución General y en las elecciones a Líder.
+
+2~ Composición y nombramiento
+
+# Los Desarrolladores son voluntarios que colaboran para hacer avanzar los objetivos del proyecto mientras participan en él, y que mantienen paquetes para el Proyecto, o realizan alguna otra tarea que el (los) Delegado(s) del Líder del Proyecto consideren adecuada.
+
+# El (o los) Delegado(s) del Líder del Proyecto puede(n) elegir no admitir nuevos Desarrolladores, o expulsar a los que ya lo sean. Si los Desarrolladores consideran que los Delegados están abusando de su autoridad pueden por supuesto anular su decisión mediante la vía de una Resolución General (vea §4.1(3), §4.2).
+
+2~ Procedimiento
+
+Los Desarrolladores pueden tomar estas decisiones según crean adecuado.
+
+1~ Los Desarrolladores mediante una Resolución General o elección
+
+2~ Atribuciones
+
+En conjunto, los Desarrolladores pueden:
+
+# Elegir o cesar al Líder del Proyecto.
+
+# Enmendar esta constitución, siempre que esté de acuerdo con una mayoría de las tres cuartas partes.
+
+# Anular cualquier decisión del Líder del Proyecto o uno de sus Delegados.
+
+# Anular cualquier decisión del Comité Técnico, siempre y cuándo estén de acuerdo dos terceras partes.
+
+# Generar documentos no técnicos sobre normas y declaraciones.
+
+Generar, sustituir y retirar documentos sobre normas y declaraciones no técnicos. -#
+
+Esto incluye documentos que describan los objetivos del proyecto, sus relaciones con otras entidades de software libre, y normas no técnicas tales como los términos de licencias de software libre a los que debe ajustarse el software de Debian.
+
+También pueden formular recomendaciones sobre los asuntos incluidos en el orden del día.
+
+_# Un Documento Fundamental (Foundation Document) es un documento o declaración clasificada como crítica para la misión y propósitos del Proyecto.
+
+_# Los Documentos Fundamentales son las obras tituladas Contrato Social de Debian (Debian Social Contract) y Directrices de Software libre de Debian (Debian Free Software Guidelines).
+
+_# La sustitución de un Documento Fundamental precisa de una mayoría de las tres cuartas partes. Se pueden generar nuevos Documentos Fundamentales y retirar los ya existentes mediante una enmienda a la lista de Documentos Fundamentales en esta constitución.
+
+# Junto con el Líder del Proyecto y SPI, tomar decisiones sobre las propiedades mantenidas en fideicomiso para propósitos relacionados con Debian (Ver §9.1.)
+
+2~ Procedimiento
+
+# Los Desarrolladores seguirán el Procedimiento Estándar de Resolución, que se indica más adelante. Se introduce una resolución o enmienda si algún desarrollador la propone y es apoyado por al menos otros 'K' Desarrolladores, o si es propuesta por el Líder del Proyecto o el Comité Técnico.
+
+# Retraso de una decisión del Líder del Proyecto o sus Delegados:
+
+_# Si el Líder del Proyecto o sus Delegados, o el Comité Técnico han tomado una decisión, los Desarrolladores pueden invalidarla aprobando una resolución que lo haga; vea s4.1(3).
+
+_# Si tal resolución es apoyada por al menos '2K' Desarrolladores, o si es propuesta por el Comité Técnico, provoca que la decisión sea congelada de forma inmediata (siempre que la propia resolución lo indique).
+
+_# Si la decisión original versaba sobre cambiar el periodo de un debate o votación, o si la resolución pretende anular uan decisión del Comité Técnico, entonces sólo hace falta el apoyo de 'K' Desarrolladores para poder congelar inmediatamente la decisión.
+
+_# Si la decisión queda postergada, se votará inmediatamente para determinar si se mantiene la decisión hasta que se produzca una votación formal al respecto, o si se deberá retrasar la implementación de la decisión original hasta entonces. No hay quorum para esta votación inmediata.
+
+_# Si el Líder del Proyecto (o su Delegado) se retracta de la decisión original, la votación se hace innecesaria, y no se lleva a cabo.
+
+# El Secretario del Proyecto toma los votos. Los votos y resultados del recuento no son revelados durante el periodo de votación; una vez terminado, el Secretario del Proyecto publicará todos los votos depositados. El periodo de votación es de dos semanas, pero el Líder del Proyecto puede variarlo en hasta una semana.
+
+# El periodo mínimo de discusión es de dos semanas, pero el Líder del Proyecto puede variarlo en hasta una semana. El Líder tiene un voto decisivo. El quorum es de 3Q.
+
+# Las propuestas, patrocinadores, enmiendas, llamadas a votación y otras acciones formales se anuncian en una lista de correo electrónico pública señalada por el (los) Delegado(s) del Líder del Proyecto. Cualquier desarrollador podrá enviar mensajes a ella.
+
+# Los votos son depositados mediante correo electrónico de una manera que el Secretario considere adecuada. El Secretario determinará, para cada votación, si los votantes pueden cambiar su voto.
+
+# Q es la mitad de la raíz cuadrada del número total de Desarrolladores. K es Q o 5, lo que sea más pequeño. Q y K no tienen por qué ser enteros, y no se les aplica redondeo.
+
+1~ El Líder del Proyecto
+
+2~ Poderes
+
+El Líder del Proyecto puede:
+
+# Nombrar Delegados o delegar decisiones en el Comité Técnico.
+
+El Líder puede definir un área de responsabilidad o una decisión específica y delegarla en otro Desarrollador o en el Comité Técnico.
+
+Una vez que una decisión en particular se haya delegado y se haya tomado, el Líder del Proyecto no puede retirar esa delegación; sin embargo, puede retirar una delegación actual de un área de responsabilidad en particular.
+
+# Ceder autoridad a otros Desarrolladores.
+
+El Líder del Proyecto puede respaldar a otros miembros del proyecto o sus opiniones, tanto si se le solicita como por propia voluntad. Sin embargo, sus declaraciones tendrán «fuerza» si y sólo si se le ha dado potestad para tomar la decisión en cuestión.
+
+# Tomar cualquier decisión que precise una acción urgente.
+
+Esto no se aplica a decisiones que se hayan vuelto urgentes de forma gradual debido a la falta de acción relevante, a menos que haya un plazo fijado.
+
+# Tomar cualquier decisión sobre la que ningún otro tenga responsabilidad.
+
+# Proponer borradores de Resoluciones Generales y enmiendas.
+
+# Junto al Comité Técnico, nombrar nuevos miembros del Comité. (Ver §6.2.)
+
+# Usar su voto decisivo cuando los Desarrolladores votan.
+
+El Líder también dispone de un voto normal en tales votaciones.
+
+# Variar el periodo de discusión de las votaciones de los desarrolladores (tal como se dijo anteriormente).
+
+# Dirigir discusiones entre Desarrolladores.
+
+El Líder debería intentar participar en las discusiones entre Desarrolladores de una manera útil, intentando mantener la discusión dentro de los temas clave. El Líder del Proyecto no debería usar su posición para promocionar sus opiniones personales.
+
+# Junto con SPI, tomar decisiones que afecten a propiedad cedida en préstamo para propósitos relacionados con Debian. (Ver §9.1.)
+
+2~ Nombramiento
+
+# El Líder del Proyecto es elegido por los Desarrolladores.
+
+# La elección comienza nueve semanas antes de que el puesto quede vacante, o (si ya es demasiado tarde) inmediatamente.
+
+# Durante las tres semanas siguientes cualquier Desarrollador puede proponerse a sí mismo como candidato a Líder del Proyecto.
+
+# Durante las siguientes tres semanas, no se podrán proponer más candidatos; los que ya lo sean deberían usar este tiempo para hacer campaña (hacer conocer sus identidades y sus opiniones). Si no hay candidatos al final del periodo de nominación, queda extendido por otras tres semanas, repetidamente si fuera necesario.
+
+# Las tres semanas siguientes constituyen el tiempo de votación, durante el cual los Desarrolladores pueden emitir su voto. Los votos destinados a la elección de un líder se mantendrán en secreto, incluso tras acabar el periodo de elecciones.
+
+# Las opciones que aparezcan en la papeleta serán las de aquellos candidatos que se hayan propuesto a sí mismos, y no se hayan retirado, además de "None Of The Above" (Ninguno de los anteriores). Si None Of The Above gana las elecciones, entonces se ha de repetir el proceso, tantas veces como sea necesario.
+
+# La decisión se tomará usando el método especificado en la sección §A.6 del Procedimiento Estándar de Resolución. El quórum es el mismo que para una Resolución General (§4.2) y la opción por defecto es "None Of The Above".
+
+# El Líder del Proyecto ejerce un año de mandato tras su elección.
+
+2~ Procedimiento
+
+El Líder del Proyecto debería intentar tomar decisiones consistentes con el consenso de las opiniones de los Desarrolladores.
+
+Cuando sea práctico, el Líder debería solicitar informalmente la opinión de los Desarrolladores
+
+El Líder debería evitar presentar sus propios puntos de vista con demasiado énfasis cuando tome decisiones en su calidad de Líder.
+
+1~ Comité técnico
+
+2~ Poderes
+
+El Comité Técnico puede:
+
+# Decidir sobre cualquier norma en materia técnica
+
+Esto incluye el contenido de los manuales de normativa técnica (policy), material de referencia para desarrolladores, paquetes de ejemplo y el comportamiento de herramientas para construcción de paquetes que no sean experimentales. En cada caso, el mantenedor original del software o documentación relevante toma las decisiones iniciales, sin embargo (Ver § 6.3(5)).
+
+# Decidir sobre cualquier materia técnica donde se solape la jurisdicción de los Desarrolladores.
+
+En los casos en que varios Desarrolladores necesiten implementar normas técnicas compatibles (por ejemplo, si no están de acuerdo en las prioridades de paquetes en conflicto, o sobre la propiedad del nombre de una orden, o sobre qué paquete es responsable de un fallo cuando ambos mantenedores están de acuerdo en que es un fallo, o sobre quién debería mantener un paquete), el comité técnico puede decidir sobre el asunto.
+
+# Tomar una decisión cuando se le pida.
+
+Cualquier persona u organismo puede delegar una decisión en el Comité Técnico, o pedirle consejo.
+
+# Imponer su decisión sobre la de un Desarrollador (precisa una mayoría de las tres cuartas partes).
+
+El Comité Técnico puede indicar a un Desarrollador que siga un curso de acción técnico en particular, incluso si no es el que desea; esto precisa una mayoría de las tres cuartas partes. Por ejemplo, el Comité puede determinar que está justificada una queja formulada por quien envía un informe de bug, y que debe implementarse la solución que propuso.
+
+# Ofrecer consejo.
+
+El Comité Técnico puede hacer anuncios formales sobre su punto de vista en cualquier asunto. Los miembros individuales pueden, por supuesto, hacer propuestas informales sobre sus puntos de vista y sobre los del comité.
+
+# Junto con el Líder del Proyecto, nombrar nuevos miembros para sí mismo, o eliminar a los existentes. (Ver §6.2.)
+
+# Nombrar al Presidente del Comité Técnico.
+
+Al Presidente lo elige el Comité de entre sus miembros. Todos los miembros del comité quedan nominados automáticamente; la votación comienza una semana antes de que el puesto quede vacante (o inmediatamente, si ya es demasiado tarde). Los miembros pueden votar por aclamación pública a cualquier colega miembro del comité, incluyéndose a sí mismos; no existe la opción predeterminada. La votación termina cuando todos los miembros hayan emitido su voto, o cuando haya terminado el periodo de votación. El resultado se determina usando el método especificado en la sección A.6 del Procedimiento Estándar de Resolución.
+
+# El Presidente puede ejercer las funciones de Líder, junto con el Secretario.
+
+Como se detalla en la §7.1(2), el Presidente del Comité Técnico y el Secretario del Proyecto pueden, en conjunto, ejercer las funciones del Líder si no hay Líder.
+
+2~ Composición
+
+# El Comité Técnico se compone de hasta 8 Desarrolladores, y normalmente debería tener al menos 4 miembros.
+
+# Cuando hayan menos de 8 miembros, el Comité Técnico puede recomendar nuevos miembros al Líder del Proyecto, quien puede escoger (individualmente) si nombrarlos o no.
+
+# Cuando haya 5 miembros o menos, el Comité Técnico puede nombrar nuevos miembros hasta que su número total llegue a 6.
+
+# Cuando el número de miembros sea de 5 o menos durante al menos una semana, el Líder del Proyecto podrá nombrar nuevos miembros hasta que su número llegue a 6, a intervalos de al menos una semana por nombramiento.
+
+# Si el Comité Técnico y el Líder del Proyecto están de acuerdo, pueden destituir o sustituir a un miembro del Comité Técnico.
+
+2~ Procedimiento
+
+# El Comité Técnico usa el Procedimiento Estándar de Resolución.
+
+Cualquier miembro del Comité Técnico puede proponer un borrador de resolución o enmienda. No hay periodo mínimo de discusión; el periodo de votación dura una semana, o hasta que el resultado esté fuera de duda. Los miembros pueden cambiar sus votos. Existe un quorum de dos.
+
+# Detalles al respecto de la votación
+
+El Presidente dispone de un voto decisivo. Cuando el Comité Técnico vota si se debe anular la autoridad de un Desarrollador que además es miembro del Comité, ese miembro no podrá votar (a menos que sea el Presidente, en cuyo caso sólo podrá usar su voto decisivo).
+
+# Discusión pública y toma de decisiones.
+
+Las discusiones, borradores de resoluciones y enmiendas, y votaciones de los miembros del comité, se hacen públicas en la lista pública de discusión del Comité Técnico. El Comité no dispone de secretario propio.
+
+# Confidencialidad de los acuerdos.
+
+El Comité Técnico puede mantener discusiones confidenciales mediante mensajes electrónicos privados, una lista de correo privada, o cualquier otro medio para discutir acuerdos del Comité. Sin embargo, las votaciones sobre dichos acuerdos deben ser públicas.
+
+# Trabajo de diseño poco detallado.
+
+El Comité Técnico no se encarga del diseño de nuevas propuestas y normas. Tal trabajo de diseño debe ser llevado acabo por individuos de forma privada o conjunta y discutida en los foros ordinarios dedicados al diseño y normativa técnicos.
+
+El Comité Técnico se restringe a sí mismo a adoptar o escoger compromisos entre soluciones y decisiones que hayan sido propuestas y razonablemente discutidas en otro lugar.
+
+Los miembros individuales del comité pueden, por supuesto, participar a título personal en cualquier aspecto del trabajo en diseño y normativa.
+
+# El Comité Técnico toma decisiones sólo como último recurso.
+
+El Comité Técnico no toma decisiones técnicas hasta que hayan fracasado otros esfuerzos para resolverlo por la vía del consenso, a menos que así se lo pida la persona u organismo responsables de dicha decisión.
+
+1~ El Secretario del Proyecto
+
+2~ Poderes
+
+El Secretario:
+
+# Recibe los votos de los Desarrolladores, y determina el número e identidad de los Desarrolladores, siempre que la constitución lo requiera.
+
+# Puede ejercer las funciones de Líder, junto con el Presidente del Comité Técnico.
+
+Si no hay Líder del Proyecto, entonces el Presidente del Comité Técnico y el Secretario del Proyecto pueden tomar decisiones mediante acuerdo si consideran imperativo hacerlo.
+
+# Juzga cualquier disputa sobre interpretaciones de la constitución.
+
+# Puede delegar parte de su autoridad en cualquier otro, o derogar tal delegación en cualquier momento.
+
+2~ Nombramiento
+
+El nuevo Secretario del Proyecto es nombrado por el Líder del Proyecto y por el Secretario que abandona el cargo.
+
+Si el Líder del Proyecto y el Secretario saliente no llegan a un acuerdo sobre el nuevo nombramiento, deberán pedir al Consejo de SPI (ver §9.1.) el nombramiento de un Secretario.
+
+Si no hay Secretario del Proyecto o el Secretario actual no está disponible, y no ha delegado la autoridad para una decisión, entonces el Presidente del Comité Técnico puede tomar tal decisión o delegarla, como Secretario en funciones.
+
+El ejercicio del Secretario del Proyecto dura 1 año, en cuyo momento debe escogerse otro Secretario o ratificarle en el cargo.
+
+2~ Procedimiento
+
+El Secretario del Proyecto debería tomar decisiones que sean justas y razonables, preferiblemente consistentes con el consenso de los Desarrolladores.
+
+Cuando actúen juntos en función del Líder del Proyecto ausente, el Presidente del Comité Técnico y el Secretario del Proyecto deberían tomar decisiones sólo cuando fuera absolutamente necesario y sólo siendo consistentes con el consenso de los Desarrolladores.
+
+1~ Los Delegados del Líder del Proyecto
+
+2~ Poderes
+
+Los Delegados del Líder del Proyecto:
+
+# disponen de los poderes que el Líder del Proyecto haya delegado en ellos;
+
+# pueden tomar ciertas decisiones que el Líder no puede tomar directamente, incluyendo la admisión o expulsión de Desarrolladores o nombramiento de personas como Desarrolladores que no mantienen paquetes. Esto evita la concentración de poder, particularmente sobre la pertenencia al proyecto de un Desarrollador, en manos del Líder del Proyecto.
+
+2~ Nombramiento
+
+Los Delegados son nombrados por el Líder del Proyecto y pueden ser reemplazados a discreción del Líder. El Líder no puede condicionar el puesto de Delegado sobre decisiones particulares que éste tome, ni puede anular una decisión del Delegado, una vez tomada.
+
+2~ Procedimiento
+
+Los Delegados toman las decisiones que crean convenientes, pero debertían intentar implementarlas de una forma técnicamente correcta o siguiente una opinión de consenso.
+
+1~ Software in the Public Interest
+
+SPI y Debian son organizaciones separadas que comparten algunos objetivos. Debian agradece la estructura de soporte legal que le ofrece SPI. Los Desarrolladores de Debian son actualemente miembros de SPI por virtud de su estatus de Desarrollador.
+
+2~ Autoridad
+
+# SPI carece de poder de decisión sobre cuestiones técnicas y de cualquier otro ámbito relacionadas con Debian, con la salvedad de que Debian no podrá imponerse a SPI en ningún caso que contravenga a su autoridad legal sobre las propiedades en poder de SPI, si bien la constitución de Debian podrá recurrir a SPI como órgano decisorio en última instancia
+
+# Debian no pretende autoridad alguna sobre SPI otra que el uso de ciertos bienes de SPI, tal como se describe más adelante, aunque se pueda conceder autoridad dentro de SPI a los Desarrolladores de Debian mediante las propias reglas de SPI.
+
+# Los Desarrolladores de Debian no son agentes comerciales ni empleados de SPI, ni unos de otros, ni de personas con autoridad en el Proyecto Debian. Una persona actuando como Desarrollador lo hace como individuo, en su propio nombre.
+
+2~ Gestión de bienes para propósitos relacionados con Debian
+
+Dado que Debian no puede poseer dinero ni bienes, cualquier donación al Proyecto Debian debe ser dirigida a SPI, que gestiona tales cuestiones.
+
+SPI garantiza lo siguiente:
+
+# SPI actuará como depositario del dinero, marcas registradas y otros bienes tangibles e intangibles y gestionará otros asuntos con propósitos relacionados con Debian.
+
+# Tales bienes serán contabilizados por separado y mantenidos en fideicomiso para dichos propósitos, decididos por Debian y SPI de acuerdo a esta sección.
+
+# SPI no dispondrá de o usará bienes mantenidos en fideicomiso para Debian sin la aprobación de Debian, que debe ser emitida por el Líder del Proyecto o mediante una Resolución General de los Desarrolladores.
+
+# SPI tomará en consideración usar o disponer de bienes mantenidos en fideicomiso para Debian cuando se lo pida el Líder del Proyecto.
+
+# SPI usará o dispondrá de bienes mantenidos en fideicomiso para Debian cuando le sea pedido mediante una Resolución General de los Desarrolladores, siempre que sea compatible con la autoridad legal de SPI.
+
+# SPI informará a los Desarrolladores mediante mensaje electrónico a una lista del Proyecto Debian cuando use o disponga de bienes mantenidos en fideicomiso para Debian.
+
+1~a A. Procedimiento Estándar de Resolución
+
+Estas reglas se aplican a la toma de decisiones comunitaria de comités y plebiscitos, tal como se indicó anteriormente.
+
+2~a1 A.1. Propuesta
+
+El procedimiento formal comienza cuando se propone y patrocina un borrador de resolución, tal como se requiere.
+
+2~a1a A.1. Discusión y Enmienda
+
+# Siguiendo la propuesta, se debe discutir la resolución. Se pueden hacer enmiendas formales proponiéndolas y patrocinándolas de acuerdo a los requerimientos de una nueva resolución, o haciéndolo directamente el proponente de la resolución original.
+
+# El proponente de la resolución puede aceptar una enmienda formal, en cuyo caso se cambia inmediatamente el borrador de la resolución formal para que se ajuste a la enmienda.
+
+# Si no se acepta una enmienda formal, o uno de los patrocinadores de la resolución no está de acuerdo con que el proponente acepte la enmienda formal, se mantiene como enmienda y pasa a ser votada.
+
+# Si una enmienda aceptada por el proponente original no es del gusto de otros, pueden proponer otra enmienda para invertir el cambio anterior (de nuevo, necesitan cumplir los requerimientos de proponente y patrocinador(es).)
+
+# El proponente o una resolución pueden sugerir cambios en el texto de la enmienda; lo cual tendrá efecto si el proponente de la enmienda está de acuerdo y ninguno de sus patrocinadores se opone. En tal caso se votará la enmienda modificada en lugar de la original.
+
+# El proponente de una resolución puede hacer cambios para corregir errores menores (por ejemplo, errores tipográficos o inconsistencias) o cambios que no alteren el significador, siempre que nadie objete en las siguientes 24 horas. En este caso, no se reinicia el periodo mínimo de discusión.
+
+2~a2 A.2. Llamada a urnas
+
+# El proponente o patrocinador de una moción o enmienda puede pedir una votación, siempre que haya pasado el tiempo mínimo de discusión (si es que lo había).
+
+# El proponente o patrocinador de una moción puede pedir una votación sobre esa resolución y todas las enmiendas relacionadas.
+
+# La persona que pide una votación indica el que cree que debería ser el texto de la resolución y cualquier enmienda relevante y, consecuentemente, el contenido de las papeletas. Sin embargo, la decisión final del contenido de las papeletas es del Secretario (Ver 7.1(1), 7.1(3) y A.3(4))
+
+# El periodo mínimo de discusión se cuenta desde el momento en que fue aceptada la última enmienda formal, o el momento en que se propuso la resolución si no se han propuesto y aceptado enmiendas.
+
+2~a3 A.3. Procedimiento de votación
+
+# Cada resolución y sus enmiendas relacionadas se votan en una única papeleta que incluye una opción para la resolución original, cada enmienda, y la opción predeterminada (si se aplica).
+
+# La opción predeterminada no tiene ningún requerimiento de supermayoría. Las opciones que no precisen explícitamente de supermayoría, tienen un requerimiento de mayoría 1:1.
+
+# Los votos se cuentan de acuerdo con las reglas en A.6. La opción predeterminada es "Further Discussion", a menos que se especifique otra cosa.
+
+# En caso de duda, el Secretario del Proyecto decidirá en materia de procedimiento.
+
+2~a4 A.4. Retirada de resoluciones o enmiendas rechazadas
+
+El proponente de una resolución o enmienda rechazada puede retirarla. En este caso, pueden aparecer nuevos proponentes para mantenerlas activas, en cuyo caso la primera persona que lo haga se convierte en el nuevo proponente y cualquier otro se convierte en patrocinador si no los había ya.
+
+El patrocinador de una resolución o enmienda puede retirarse (a menos que sea aceptada).
+
+Si la retirada del proponente o patrocinadores implica que la resolución no tiene proponente o suficientes patrocinadores, no será llevada a votación a menos que se rectifique antes de que la resolución expire.
+
+2~a5 A.5. Expiración
+
+Si una resolución propuesta no ha sido discutida, enmendada, votada o movida de alguna manera durante 4 semanas el secretario puede anunciar que está siendo retirada. Si ninguno de los patrocinadores de cualquiera de las propuestas objeta durante una semana, la resolución se retira.
+
+El secretario también puede incluir sugerencias sobre cómo proceder, si fuera apropiado.
+
+2~a6 A.6. Recuento de votos
+
+# La papeleta de cada votante califica las opciones sobre las que se vota. No hace falta calificar todas las opciones. Las opciones calificadas se consideran preferidas sobre todas las que no lo hayan sido. Los votantes pueden dar la misma calificación a las opciones. Se considera que las no calificadas tienen la misma calificación entre ellas. Se incluirán en la Llamada al voto los detalles de la manera en que se debe rellenar la papeleta.
+
+# Si la papeleta precisa un quórum R, cualquier opción diferente a la predeterminada que no obtenga al menos R votos calificándola por encima de la opción predeterminada se elimina de toda consideración.
+
+# Cualquier opción (que no sea la predeterminada) que no venza a la predeterminada por la proporción de mayoría precisada se elimina de toda consideración.
+
+_# Dadas dos opciones A y B, V(A,B) es el número de votantes que prefieren la opción A sobre la opción B.
+
+_# Una opción A vence a la opción predeterminada D por una proporción de mayoría N, si V(A, D) es estrictamente mayor que N * V(D,A).
+
+_# Si A necesita una supermayoría de S:1, su proporción de mayoría es S; si no, su proporción de mayoría es 1.
+
+# De la lista de opciones sin eliminar, generamos una lista de derrotas a pares.
+
+_# Una opción A vence a una opción B, si V(A,B) es estrictamente mayor que V(B,A).
+
+# De una lista de derrotas a pares (sin eliminar), generamos un conjunto de derrotas transitivas.
+
+_# Una opción A derrota transitivamente a una opción C si A derrota a C o si hay otra opción B donde A derrota a B Y B derrota transitivamente a C.
+
+# Construimos el conjunto de Schwartz partiendo del conjunto de derrotas transitivas.
+
+_# Una opción A está en el conjunto de Schwartz si para todas las opciones B, bien A derrota transitivamente a B, o B no derrota transitivamente a A.
+
+# Si hay derrotas entre opciones en el conjunto de Schwartz, eliminamos a la más débil de tales derrotas de la lista de derrotas por pares, y volvemos al quinto paso.
+
+_# Una derrota (A,X) es más débil que una derrota (B,Y) si V(A,X) es menor que V(B,Y). Además, (A,X) es más débil que (B,Y) si V(A,X) es igual a V(B,Y) y V(X,A) es mayor que V(Y,B).
+
+_# La derrota más débil es aquella que no tiene ninguna derrota más débil que ella. Puede haber más de una de tales derrotas.
+
+# Si no hay derrotas dentro del conjunto de Schwartz, entonces el ganador se escoge de entre las opciones en dicho conjunto. Si sólo hay una de tales opciones, es la ganadora. Si hay varias, el elector con el voto de calidad escoge cual de estas opciones gana.
+
+Nota: Las opciones que los votantes califiquen por encima de la opción predeterminada son aquellas que encuentran aceptables. Las opciones calificadas por debajo de la predeterminada son las que encuentran inaceptables.
+
+Cuando se deba usar el Procedimiento Estándar de Resolución, el texto que se refiera a ello debe especificar si es suficiente tener un borrador o patrocinadores de la resolución propuesta, cual es el periodo mínimo de discusión, y el periodo de votación. También se debe especificar la necesidad de una mayoría absoluta o el quorum (y la opción por defecto) necesario.
+
+1~b B. Uso del lenguaje y tipografía
+
+N. del T.: se refiere al original en ingles.
+
+EL presente indicativo (`is', por ejemplo) indica que la frase es una regla de esta constitución. `May' o `can' indica que la persona u organismo puede actuar a discreción. `Should' indica que se consideraría bien la obediencia a dicha frase, pero no es vinculante. El texto marcado como cita, tal como éste, indica la base lógica del texto, y no forma parte de la constitución. Se debe usar sólo como ayuda en caso de duda.
+
+% Volver a la página principal de Debian.
+% Cómo modificar el idioma por defecto de los documentos
+% Para informar de un problema con el servidor web, por favor, envíe un correo (en inglés) a debian-www@lists.debian.org. Para consultar información de contacto adicional consulte la página de contactos de Debian.
+% Última modificación: mar, 14 de nov de 2006, 15:44:29 UTC
+% Proyecto Debian
+% Elija un servidor cerca de usted
+% Nota: La página original es más nueva que esta traducción.
+% Constitución de Debian
+% Constitución del Proyecto Debian (v1.2)
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/es/debian_social_contract_v1.1.sst b/debian/data/doc/sisu/markup-samples/samples/v3/es/debian_social_contract_v1.1.sst
new file mode 100644
index 00000000..8625fce9
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/es/debian_social_contract_v1.1.sst
@@ -0,0 +1,136 @@
+% SiSU 2.0
+
+@title: Contrato social de Debian
+ :subtitle: Debian Social Contract (v1.1)
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:policy:social contract;GNU/Linux:debian:social contract;language:Spanish
+
+@date:
+ :published: 2004-04-26
+ :created: 1997-07-05
+ :issued: 1997-07-05
+ :valid: 2004-04-26
+ :available: 2004-04-26
+ :modified: 2004-04-26
+
+@language:
+ :document: Spanish
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.es.html <br>"Debian" y el logotipo de Debian http://www.debian.org/logos/ son marcas registradas de Software in the Public Interest, Inc.
+ :license: OJO: Esta es una traducción de la licencia original, y no tiene ningún valor jurídico http://www.debian.org/license.en.html. Si desea ver la versión verdadera debe acudir a la licencia original, en este mismo servidor.<br>Este material sólo puede ser distribuido sujeto a los términos y condiciones indicados en la Licencia de publicaciones abiertas, borrador v1.0 o posterior (puede consultar nuestra copia local http://www.debian.org/opl ; la última versión suele estar disponible en http://www.opencontent.org/openpub/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/social_contract
+ {Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
+
+@make:
+ :breaks: new=C; break=1
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Contrato social de Debian
+
+1~pre [Prefix]-#
+
+La versión 1.1 ratificada el 26 de abril de 2004 deroga la versión 1.0 ratificada el 5 de julio de 1997.
+
+El proyecto Debian, creador del sistema Debian GNU/Linux, ha creado el contrato social de Debian. Este documento es una declaración de intenciones por nuestra parte y un conjunto de principios que acatamos. La parte del contrato llamada directrices de software libre de Debian (Debian Free Software Guidelines, DFSG)— diseñada inicialmente como un un conjunto de criterios para definir lo que es software libre—, ha sido adoptada posteriormente por la comunidad de software libre como base para la definición de Open Source.
+
+1~ «Contrato social» con la comunidad de software libre
+
+2~ 1. Debian permanecerá 100% libre
+
+Las «Las directrices de software libre de Debian» (DFSG) son el criterio que nosotros utilizamos para determinar si el software es «libre» o no. Prometemos mantener el sistema GNU/Linux así como todos sus componentes completamente libres de acuerdo con este criterio. No obstante, daremos soporte también a aquellos usuarios que desarrollen y ejecuten software no libre en Debian pero nunca haremos que el sistema tenga que utilizar obligatoriamente un componente que no sea libre.
+
+2~ 2. Contribuiremos a la comunidad de software libre
+
+Cuando escribamos nuevos componentes del sistema Debian, los licenciaremos de forma consistente con nuestra definición de software libre. Haremos el mejor sistema que podamos, de forma que el software libre tenga amplia difusión y uso. Enviaremos parches, mejoras, peticiones de los usuarios, etc a los autores originales (esto se conoce en inglés como upstream, N. del T.) del software incluido en nuestro sistema.
+
+2~ 3. No ocultaremos los problemas
+
+Mantendremos nuestra base de datos de informes de error accesible al público en todo momento. Los informes de error que los usuarios envíen serán visibles por el resto de usuarios de forma inmediata.
+
+2~ 4. Nuestra prioridad son nuestros usuarios y el software libre
+
+Nos guiaremos por las necesidades de nuestros usuarios y de la comunidad del software libre. Sus intereses serán una prioridad para nosotros. Daremos soporte a las necesidades de nuestros usuarios para que puedan trabajar en muchos tipos distintos de entornos de trabajo. No pondremos objeciones al software no libre que vaya a ejecutarse sobre Debian ni cobraremos a las personas que quieran desarrollar o usar ese tipo de software (no libre). Permitiremos a otros crear distribuciones de valor añadido basadas en Debian sin cobrarles nada por ello. Es más, entregaremos un sistema integrado de alta calidad sin restricciones legales que pudieran prevenir este tipo de uso.
+
+2~ 5. Trabajos que no siguen nuestros estándares de software libre
+
+Reconocemos que algunos de nuestros usuarios necesitan usar trabajos que no sigan las directrices de software libre de Debian (DFSG). Por ello, hemos creado las secciones «contrib» y «non-free» en nuestro archivo para estos trabajos. Los paquetes en estas secciones no son parte del sistema Debian, aunque ha sido configurado para usarse con Debian. Animamos a los distribuidores de CDs a que lean las licencias de los paquetes en estas secciones para poder determinar si pueden distribuir este software en sus CDs. Así pues, aunque los trabajos que no sean libres no son parte de Debian, damos soporte para su uso, y proporcionamos infraestructuras (como nuestro sistema de informe de errores y listas de distribución) para paquetes no libres.
+
+1~ Las directrices de software libre de Debian (DFSG)
+
+2~ 1. Libre redistribución
+
+La licencia de un componente de Debian no puede restringir a un tercero el vender o entregar el programa como parte de una distribución mayor que contiene programas de diferentes fuentes. La licencia no debe solicitar «royalties» u otras comisiones para esta venta.
+
+2~ 2. Código fuente
+
+El programa debe incluir el código fuente completo, y debe permitir la distribución en forma de código fuente y en forma compilada (binario).
+
+2~ 3. Trabajos derivados
+
+La licencia debe permitir modificaciones y trabajos derivados y debe permitir que estos se distribuyan bajo los mismos términos que la licencia del programa original.
+
+2~ 4. Integridad del código fuente del autor
+
+La licencia puede restringir la distribución del código fuente en forma modificada *sólo* si la licencia permite la distribución de «parches» («patch files») para poder modificar el código fuente original del programa en el momento de compilarlo. La licencia debe permitir explícitamente la distribución de software a partir de código fuente modificado. La licencia puede obligar a los trabajos derivados a llevar un nombre o número de versión diferentes del programa original (Esto es un compromiso. El grupo de Debian anima a todos los autores a no restringir ningún fichero, fuente o compilado, de ser modificado.)
+
+2~ 5. No discriminación contra personas o grupos
+
+La licencia no debe discriminar a ninguna persona o grupo de personas.
+
+2~ 6. No discriminación en función de la finalidad perseguida
+
+La licencia no puede restringir el uso del programa para una finalidad determinada. Por ejemplo, no puede restringir el uso del programa a empresas con fines comerciales, o en investigación genética.
+
+2~ 7. Distribución de la licencia
+
+Los derechos y libertades de uso asociados al programa deben aplicarse en la misma forma a todos aquellos a los que se redistribuya el programa, sin necesidad de pedir una licencia adicional para estas terceras partes.
+
+2~ 8. La licencia no ha de ser específica para Debian
+
+Los derechos asociados al programa no deben depender de que el programa sea parte o no del sistema Debian. Si el programa es extraído de Debian y usado o distribuido sin Debian, pero manteniendo el resto de las condiciones de la licencia, todos aquellos a los que el programa se redistribuya deben tener los mismos derechos que los dados cuando forma parte de Debian.
+
+2~ 9. La licencia no debe contaminar a otros programas
+
+La licencia no debe poner restricciones sobre otros programas que se distribuyan junto con el programa licenciado. Por ejemplo, la licencia no puede insistir que todos los demás programas distribuidos sobre el mismo medio deben ser software libre.
+
+2~ 10. Ejemplos de licencias
+
+Las licencias «GPL», «BSD», y « Artística» son ejemplos de licencias que nosotros consideramos «libres».
+
+La expresión «contrato social con la comunidad de software libre» fue sugerida por Ean Schuessler. El primer borrador de este documento fue escrito por Bruce Perens, fue modificado por los demás desarrolladores de Debian durante una conferencia por correo electrónico que duró un mes (junio de 1997) y finalmente aceptado como la normativa pública del proyecto Debian.
+
+Posteriormente, Bruce Perens eliminó las referencias específicas a Debian en las directrices de Debian para el Software Libre (DFSG), creando “la definición de Open Source”.
+
+Cualquier otra organización puede llevar a cabo trabajos derivados a partir de este documento. Por favor, haga referencia al proyecto Debian en tal caso.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/fi/debian_social_contract_v1.1.sst b/debian/data/doc/sisu/markup-samples/samples/v3/fi/debian_social_contract_v1.1.sst
new file mode 100644
index 00000000..0f66e192
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/fi/debian_social_contract_v1.1.sst
@@ -0,0 +1,138 @@
+% SiSU 2.0
+
+@title: Debianin yhteisösopimus
+ :subtitle: Debian Social Contract (v1.1)
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:policy:social contract;GNU/Linux:debian:social contract;language:Finnish
+
+@date:
+ :published: 2004-04-26
+ :created: 1997-07-05
+ :issued: 1997-07-05
+ :valid: 2004-04-26
+ :available: 2004-04-26
+ :modified: 2004-04-26
+
+@language:
+ :document: Finnish
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.fi.html <br>"Debian" ja Debian-logo http://www.debian.org/logos/ ovat Software in the Public Interest, Inc.:n tavaramerkkejä.<br> http://www.debian.org/license.en.html
+ :license: Tätä materiaalia voidaan levittää ainoastaan Open Publication License, vedos v1.0 (paikallinen kopiomme luettavaksesi http://www.debian.org/opl ) tai myöhemmän määräysten ja ehtojen mukaisesti. Uusin versio on saatavilla yleensä osoitteesta http://www.opencontent.org/.
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/social_contract
+ {Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
+
+@make:
+ :breaks: new=C; break=1
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Debianin yhteisösopimus
+
+1~pre [Prefix]-#
+
+Versio 1.1 ratifioitiin 26. huhtikuuta 2004. Se korvaa version 1.0, joka ratifioitiin 5. heinäkuuta 1997.
+
+Debian, joka koostuu Debian GNU/Linux -järjestelmän tekijöistä, on luonut Debianin yhteisösopimuksen. Sen osan sopimuksesta, joka tunnetaan nimellä Debianin vapaiden ohjelmistojen ohjeisto (Debian Free Software Guidelines (DFSG)) ja jonka oli alun perin tarkoitus määrittää joukko sitoumuksia, jotka aiomme pitää, on vapaiden ohjelmistojen yhteisö ottanut Open Source -määritelmän pohjaksi.
+
+1~ Yhteisösopimus vapaiden ohjelmistojen yhteisön kanssa
+
+2~ 1. Debian pysyy täysin vapaana
+
+Olemme luoneet ohjeiston nimeltään Debianin vapaiden ohjelmistojen ohjeisto (Debian Free Software Guidelines, DFSG), jonka perusteella määrittelemme milloin jokin teos on vapaa. Lupaamme, että Debian-järjestelmä kaikkine osineen on vapaa kyseisen ohjeiston määrittelemässä mielessä. Tuemme ihmisiä, jotka luovat tai käyttävät sekä vapaita että epävapaita teoksia Debian-järjestelmässä. Emme koskaan muuta järjestelmää sellaiseksi, että se edellyttäisi epävapaiden osien käyttämistä.
+
+2~ 2. Annamme takaisin vapaiden ohjelmistojen yhteisölle
+
+Kun teemme Debian-järjestelmään uusia osia, lisensoimme ne Debianin vapaiden ohjelmistojen ohjeiston mukaisesti. Teemme niin hyvän järjestelmän kuin suinkin pystymme, jotta vapaita teoksia levitettäisiin ja käytettäisiin laajalti. Välitämme korjaukset, parannukset ja käyttäjien toiveet "ylävirtaan" eli järjestelmäämme sisältyvien teosten tekijöille.
+
+2~ 3. Emme kätke ongelmia
+
+Pidämme vikailmoitustietokantamme jatkuvasti kaikkien nähtävillä. Sähköisesti toimitetut vikailmoitukset tulevat ripeästi muiden nähtäville.
+
+2~ 4. Käyttäjämme ja vapaat ohjelmistot ovat tärkeimmät prioriteettimme
+
+Käyttäjiemme ja vapaiden ohjelmistojen yhteisön tarpeet ohjaavat meitä, ja asetamme nämä tarpeet ensimmäiselle sijalle. Tuemme käyttäjiemme tarpeita monenlaisissa tietojenkäsittely-ympäristöissä. Emme vastusta Debian-järjestelmissä käytettäväksi tarkoitettuja epävapaita teoksia emmekä yritä periä maksua henkilöiltä, jotka luovat tai käyttävät sellaisia teoksia. Sallimme muiden luoda ilman maksua käyttöjärjestelmäjakeluita, joihin sisältyy sekä Debian-järjestelmä että muita teoksia. Näiden tavoitteiden edistämiseksi tarjoamme korkealaatuisista, keskenään hyvin toimivista osista muodostuvan järjestelmän ilman mitään lakiin perustuvia rajoituksia, jotka voisivat estää edellä kuvatun mukaisen käytön.
+
+2~ 5. Teokset, jotka eivät täytä vapaiden ohjelmistojen vaatimuksiamme
+
+Tiedostamme, että joidenkin käyttäjiemme on välttämätöntä käyttää teoksia, jotka eivät vastaa Debianin vapaiden ohjelmistojen ohjeiston vaatimuksia. Tällaisia teoksia varten olemme luoneet tiedostoarkistoomme "contrib"- ja "non-free"-osiot. Näihin osioihin kuuluvat paketit eivät ole osa Debian-järjestelmää, vaikka ne onkin mukautettu toimimaan Debianissa. Kannustamme CD-valmistajia lukemaan näissä osioissa olevien pakettien lisenssiehdot ja selvittämään, voivatko he levittää kyseisiä paketteja CD-levyillään. Näin ollen, vaikka epävapaat teokset eivät kuulu Debianiin, tuemme niiden käyttöä ja tarjoamme epävapaiden pakettien tueksi infrastruktuurin (kuten vianseurantajärjestelmän ja sähköpostilistat).
+
+1~ Debianin vapaiden ohjelmistojen ohjeisto (DFSG)
+
+2~ 1. Vapaa levitys
+
+Debianin osan levitysehdot eivät saa rajoittaa ketään myymästä tai antamasta kyseistä ohjelmistoa osana ohjelmistokokoelmaa, joka sisältää eri lähteistä saatuja ohjelmia. Nämä levitysehdot eivät saa vaatia myyjältä rojalteja tai muita maksuja.
+
+2~ 2. Lähdekoodi
+
+Ohjelman mukana tulee olla sen lähdekoodi, ja pitää olla sallittua levittää ohjelmaa lähdekielisenä kohdekielisen lisäksi.
+
+2~ 3. Johdannaisteokset
+
+Ohjelman levitysehtojen tulee sallia muutoksien ja johdannaisteosten tekeminen ja myös sallia näiden levittäminen samoin ehdoin kuin alkuperäisen ohjelman.
+
+2~ 4. Alkuperäisen lähdekoodin eheys
+
+Ohjelman levitysehdot saavat rajoittaa muutetun lähdekoodin levitystä _vain_, jos se sallii "muutostiedostojen" (patch files) levityksen lähdekoodin kanssa tarkoituksena muuttaa ohjelmaa käännösaikana. Levitysehtojen tulee erityisesti sallia muutetusta lähdekoodista tuotetun ohjelman levittäminen. Ne saavat vaatia, että johdannaisteoksien nimenä tai versionumerona käytetään jotain muuta kuin alkuperäisen ohjelman nimeä tai versionumeroa. (Tämä on kompromissi. Debian suosittelee kaikille ohjelmien tekijöille pidättäytymistä minkäänlaisten tiedostojen, lähde- tai kohdekielisten, muuttamisen kieltämisestä.)
+
+2~ 5. Ei ihmisten tai ihmisryhmien syrjintää
+
+Ohjelman levitysehdot eivät saa syrjiä ketään ihmistä tai mitään ihmisryhmää.
+
+2~ 6. Ei toiminnan alojen syrjintää
+
+Ohjelman levitysehdot eivät saa estää ketään käyttämästä ohjelmaa tietyllä alalla. Esimerkiksi ohjelman käyttöä yrityksessä ei saa rajoittaa, tai sen käyttöä geenitutkimuksessa.
+
+2~ 7. Levitysehtojen jatkuvuus
+
+Ohjelmaan liittyvien oikeuksien tulee koskea kaikkia, jotka ovat hankkineet ohjelmasta kappaleen ilman, että heidän tarvitsee hankkia erillinen lisenssi.
+
+2~ 8. Levityslupa ei saa olla vain Debianille
+
+Ohjelmaan liittyvät oikeudet eivät saa riippua ohjelman olemisesta osa Debiania. Jos ohjelma irrotetaan Debianista ja sitä käytetään tai levitetään ilman Debiania mutta muuten levitysehtojen mukaisesti, kaikilla osapuolilla tulee olla samat oikeudet, jotka annetaan Debian-järjestelmän yhteydessä.
+
+2~ 9. Levitysehdot eivät saa saastuttaa muita ohjelmia
+
+Ohjelman levitysehdot eivät saa asettaa rajoituksia muille ohjelmille, jotka levitetään kyseisen ohjelman kanssa. Ehdot eivät saa esimerkiksi vaatia, että muiden samalla levitysmedialla olevien ohjelmien tulee olla vapaita.
+
+2~ 10. Esimerkkilisenssejä
+
+"GPL", "BSD" ja "Artistic"-lisenssit ovat esimerkkejä lisensseistä, jotka ovat mielestämme "vapaita".
+
+Ean Schuessler ehdotti ajatusta tuoda julki "yhteiskunnallinen sopimuksemme vapaiden ohjelmistojen yhteisön kanssa". Bruce Perens kirjoitti tämän asiakirjan ensimmäisen luonnoksen ja paranteli sitä Debian-kehittäjien kommenttien perusteella kuukauden pituisen sähköpostikonferenssin aikana kesäkuussa 1997, ja joka sitten hyväksyttiin julkisesti esitettäväksi Debian-projektin linjaksi.
+
+Bruce Perens poisti myöhemmin Debian-spesifiset viittaukset Debianin vapaiden ohjelmien ohjeistosta luodakseen “Open Source -määritelmän”.
+
+Muut yhteisöt saavat luoda johdannaisia tästä asiakirjasta. Toivomme, että tunnustatte Debian-projektin roolin asiakirjan luomisessa, jos näin teette.
+
+Takaisin Debian-projektin kotisivulle.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/fr/debian_constitution_v1.2.sst b/debian/data/doc/sisu/markup-samples/samples/v3/fr/debian_constitution_v1.2.sst
new file mode 100644
index 00000000..1894c175
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/fr/debian_constitution_v1.2.sst
@@ -0,0 +1,508 @@
+% SiSU 2.0
+
+% Dernière modification : jeudi 2 novembre 2006 06:33:05 UTC
+% Copyright © 1997-2006 SPI; voir les termes de la licence.
+% Debian est une marque déposée de Software in the Public Interest, Inc.
+% Note : le document original est plus récent que cette traduction.
+% Constitution Debian
+% Constitution du Projet Debian (v1.2)
+
+@title: Constitution Debian
+ :subtitle: Constitution du Projet Debian (v1.2) [This Document has been Superseded by v1.3]
+ :edition: v1.2
+ :note: [This Document has been Superseded by v1.3]
+
+@creator:
+ :author: Debian Project
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.da.html <br>« Debian » et le logo Debian sont des marques déposées appartenant à Software in the Public Interest, Inc.<br>En cas de litige, seule la version originale de cette page a valeur au regard de la loi http://www.debian.org/license.en.html.
+ :license: Ce matériel ne peut être distribué que conformément aux termes et conditions présentés dans la Licence de Publication Ouverte (Open Publication License), Draft v.1.0 ou suivantes. (Vous pouvez lire notre copie locale http://www.debian.org/opl, dont la version la plus récente est généralement disponible à http://www.opencontent.org/ ).
+
+@date:
+ :published: 2003-10-29
+ :created: 1998-12-03
+ :issued: 1998-12-03
+ :valid: 2003-10-29
+ :available: 2003-10-29
+ :modified: 2006-11-02
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:constitution;GNU/Linux:debian:constitution;language:French
+
+@language:
+ :document: French
+ :original: English
+
+@make:
+ :num_top: 1
+ :breaks: new=C
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/devel/constitution
+ {SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
+ {Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2.default/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original
+
+:A~ Constitution Debian
+
+:B~ Constitution du Projet Debian (v1.2) [This Document has been Superseded by v1.3]
+
+1~pre [Prefix]-#
+
+Version 1.2 ratifiée le 29 octobre 2003. Remplace la Version 1.1 ratifiée le 21 juin 2003, qui elle même remplace la Version 1.0 ratifiée le 2 décembre 1998.
+
+1~ Introduction
+
+Le Projet Debian est une association d'individus qui ont pris pour cause commune la création d'un système d'exploitation libre.
+
+Ce document décrit la structure organisationnelle pour les prises de décisions formelles dans le Projet. Il ne décrit pas les buts du Projet ni comment il les atteint, ni ne contient aucune règle excepté celles directement relatives au processus de prise de décision.
+
+1~ Corps et individus prenant les décisions
+
+Chaque décision dans le Projet est faite par un ou plus des suivants :
+
+# Les Développeurs, par Résolution Générale ou par vote ;
+
+# Le Chef du Projet ;
+
+# Le Comité Technique et/ou son Président ;
+
+# Le Développeur individuel travaillant sur une certaine tâche ;
+
+# Des Délégués nommés par le Chef du Projet pour des tâches spécifiques ;
+
+# Le Secrétaire du Projet.
+
+La plus grosse partie du reste de ce document esquissera les pouvoirs de ces corps, leur composition et leur nomination, et les procédures de leurs prises de décisions. Les pouvoirs d'une personne ou d'un corps peuvent être sujet à révision et/ou limitation par d'autres; dans ce cas le passage concernant le corps ou la personne pouvant faire la révision l'indiquera. Dans la liste ci dessus, une personne ou un corps est habituellement cité avant les personnes ou les corps dont ils peuvent outrepasser les décisions ou qu'ils nomment (ou aident à nommer) - mais ceux qui sont cités avant ne peuvent pas tous outrepasser les décisions de tous ceux qui sont cités ensuite.
+
+2~ Règles Générales
+
+# Rien dans cette constitution n'impose à quiconque d'obligation de faire un travail pour le Projet. Une personne qui ne veut pas faire une tâche qui lui a été déléguée ou assignée n'a pas à la faire. Cependant, elle ne doit pas travailler activement contre ces règles et les décisions prises convenablement qui en découlent.
+
+# Une personne peut cumuler plusieurs postes, excepté le fait que le Chef du Projet, le Secrétaire du Projet et le Président du Comité Technique doivent être distincts, et que le Chef ne peut pas les nommer pour être leurs propres Délégués.
+
+# Une personne peut quitter le Projet ou démissionner d'un poste particulier qu'elle tient, à n'importe quel moment, en le disant publiquement.
+
+1~ Les Développeurs Individuels
+
+2~ Pouvoirs
+
+Un Développeur individuel peut
+
+# prendre n'importe quelle décision technique ou non technique en rapport avec son propre travail ;
+
+# proposer ou soutenir des projets de Résolutions Générales ;
+
+# se proposer lui même comme candidat pour les élections au poste de Chef du Projet ;
+
+# voter les Résolutions Générales et lors des élections au poste de Chef du Projet.
+
+2~ Composition et nomination
+
+# Les développeurs sont des volontaires qui s'accordent à poursuivre les buts du Projet en ce qu'ils y participent, et qui maintiennent des paquets pour le Projet ou font tout autre travail que les Délégués du Chef du Projet considèrent utile.
+
+# Les Délégués du Chef du Projet peuvent choisir de ne pas admettre de nouveaux Développeurs, ou d'expulser des Développeurs existant. Si les Développeurs pensent que les Délégués abusent de leur autorité ils peuvent bien sûr outrepasser la décision par Résolution Générale - voir §4.1(3), §4.2.
+
+2~ Procédure
+
+Les Développeurs peuvent prendre ces décisions comme ils le souhaitent.
+
+1~ Les Développeurs par Résolution Générale ou élection
+
+2~ Pouvoirs
+
+Ensemble, les Développeurs peuvent :
+
+# Nommer ou rétrograder le Chef du Projet.
+
+# Amender cette constitution, pourvu qu'ils soient d'accord avec une majorité de 3 contre 1.
+
+# Outrepasser n'importe quelle décision du Chef du Projet ou d'un Délégué.
+
+# Outrepasser n'importe quelle décision du Comité Technique, pourvu qu'ils soient d'accord avec une majorité de 2 contre 1.
+
+# Produire, mettre à jour ou retirer des déclarations ou des documents régulateurs non techniques.
+
+Ceci inclut des documents décrivant les buts du projet, ses relations avec d'autres entités du logiciel libre, et des règles non techniques comme les termes de la licence de logiciel libre que les logiciels Debian doivent satisfaire.
+
+Cela peut aussi inclure des déclarations de position concernant les problèmes du jour.
+
+_# Un document fondateur (« Foundation Document ») est un document ou une déclaration considéré comme critique pour la mission ou les objectifs du Projet.
+
+_# Les documents fondateurs sont les travaux appelés Contrat social Debian (« Debian Social Contract ») et Directives Debian pour le logiciel libre (« Debian Free Software Guidelines »).
+
+_# Il est nécessaire d'avoir une majorité de 3:1 pour mettre à jour un document fondateur. Les nouveaux documents fondateurs sont produits et les documents fondateurs existants sont retirés, en amendant la liste des documents fondateurs dans cette constitution.
+
+# Ensemble avec le Chef du Projet et SPI, prendre des décisions à propos des biens mis en commun pour les besoins de Debian. (Voir §9.1.)
+
+2~ Procédure
+
+# Les Développeurs suivent la Procédure Standard de Résolution, ci dessous. Une résolution ou un amendement est introduit si il est proposé par n'importe quel Développeur et soutenu par au moins K autres Développeurs, ou si il est proposé par le Chef du Projet ou le Comité Technique.
+
+# Retarder une décision du Chef du Projet ou d'un Délégué :
+
+_# Si le Chef du Projet ou son Délégué, ou le Comité Technique, a pris une décision, alors les Développeurs peuvent l'outrepasser en adoptant une résolution pour cela ; voir s4.1(3).
+
+_# Si une telle résolution est soutenue par au moins 2K Développeurs, ou si elle est proposée par le Comité Technique, la résolution suspend la décision immédiatement (pourvu que la résolution elle même le demande).
+
+_# Si la décision originale était de changer la période de discussion ou de vote, ou si la résolution est d'outrepasser le Comité Technique, alors seulement K Développeurs doivent soutenir la résolution pour pouvoir suspendre immédiatement la décision.
+
+_# Si la décision est suspendue, un vote immédiat est tenu pour déterminer si la décision sera applicable jusqu'à ce que le vote complet sur la décision soit fait ou si l'implémentation de la décision originale sera retardée jusqu'à ce moment. Il n'y a pas de quorum pour ce vote procédural immédiat.
+
+_# Si le Chef du Projet (ou le Délégué) retire la décision originale, le vote devient inutile, et n'est plus poursuivi.
+
+# Les votes sont reçus par le Secrétaire du Projet. Les votes, les contrôles et les résultats ne doivent pas être révélés pendant la durée du scrutin ; après le scrutin, le Secrétaire du Projet liste tous les contenus des votes. La durée du scrutin est de 2 semaines, mais elle peut être modifiée d'au plus une semaine par le Chef du Projet.
+
+# La période de discussion minimum est de 2 semaines, mais elle peut être modifiée d'au plus une semaine par le Chef du Projet. Le Chef du Projet a un vote discriminant. Il y a un quorum de 3Q.
+
+# Les propositions, soutiens, amendements, appels au vote et autres actions formelles sont faites par annonces sur une liste de discussion électronique à lecture publique désignée par le Délégué du Chef du Projet; n'importe quel Développeur peut poster sur celle-ci.
+
+# Les votes sont envoyés par courrier électronique d'une façon qui convienne au Secrétaire. Le Secrétaire détermine pour chaque scrutin si les votants peuvent changer leurs votes.
+
+# Q est la moitié de la racine carré du nombre de Développeurs courant. K est le minimum de Q et de 5. Q et K ne sont pas forcément entiers et ne sont pas arrondis.
+
+1~ Le Chef du Projet
+
+2~ Pouvoirs
+
+Le Chef du Projet peut :
+
+# Nommer des Délégués ou déléguer des décisions au Comité Technique.
+
+Le Chef peut définir un domaine de responsabilité ou une décision courante spécifique et la confier à un autre Développeur ou au Comité Technique.
+
+Une fois qu'une décision particulière a été déléguée et faite, le Chef du Projet ne peut retirer cette délégation ; cependant, il peut retirer une délégation courante d'une aire de responsabilité particulière.
+
+# Prêter de l'autorité à d'autres Développeurs.
+
+Le Chef de Projet peut faire des déclarations de soutien à des points de vue ou à d'autres membres du projet, que cela lui soit demandé ou non ; ces déclarations ont du poids si et seulement si le Chef a le pouvoir de prendre la décision en question.
+
+# Prendre n'importe quelle décision qui demande une action urgente.
+
+Cela ne s'applique pas aux décisions qui sont seulement devenues graduellement urgente à cause d'un manque d'action significative, sauf s'il y a une date butoir.
+
+# Prendre n'importe quelle décision pour laquelle personne d'autre n'a de responsabilité.
+
+# Proposer des Résolutions Générales et des amendements.
+
+# Ensemble avec le Comité Technique, nommer de nouveaux membres au Comité. (Voir §6.2.)
+
+# Utiliser un vote discriminant quand les Développeurs votent.
+
+Le Chef de Projet a aussi un vote normal dans ces scrutins.
+
+# Changer la période de discussion des vote des Développeurs (comme ci-dessus).
+
+# Mener les discussions parmi les Développeurs.
+
+Le Chef de Projet devrait essayer de participer aux discussions parmi les Développeurs d'une manière utile qui cherche à amener la discussion à traiter des problèmes clés en suspend. Le Chef de Projet ne devrait pas utiliser sa position d'autorité pour promouvoir ses vues personnelles.
+
+# Ensemble avec SPI, prendre les décisions affectant les biens possédés en commun pour les besoins relatifs à Debian. (Voir §9.1.)
+
+2~ Nomination
+
+# Le Chef de Projet est élu par les Développeurs.
+
+# Une élection commence neuf semaines avant que le poste de chef ne devienne vacant, ou (si c'est déjà trop tard) immédiatement.
+
+# Pendant les trois semaines suivantes n'importe quel Développeur peut se porter candidat au poste de Chef du Projet.
+
+# Pendant les trois semaines suivantes, aucun candidat ne peut plus se présenter ; les candidats devraient utiliser cette période pour faire campagne (pour faire connaître leurs identités et leurs positions). S'il n'y a pas de candidats à la fin de la période de désignation alors cette période est étendue de trois semaines supplémentaires, répétitivement si nécessaire.
+
+# Les trois semaines suivantes sont la période de scrutin pendant laquelle les Développeurs peuvent envoyer leurs votes. Les votes de l'élection du chef sont tenus secrets, même après que l'élection est finie.
+
+# Les choix possibles sur les bulletins seront les candidats qui se sont désignés et qui ne se sont pas encore retirés, plus le choix « None Of The Above » (Aucun de ceux qui précèdent). Si le choix « None Of The Above » gagne l'élection alors la procédure d'élection est recommencée, plusieurs fois si nécessaire.
+
+# La décision sera prise en utilisant la méthode spécifiée dans la section §A.6 de la Procédure de Résolution Standard. Le quorum est le même que pour une Résolution Générale (§4.2) et l'option par défaut est « None Of The Above ».
+
+# Le Chef du Projet est désigné pour une année à compter de son élection.
+
+2~ Procédure
+
+Le Chef du Projet devrait essayer de prendre des décisions qui sont consistantes avec le consensus d'opinions des Développeurs.
+
+Lorsque c'est possible le Chef du Projet devrait solliciter de manière informelle les opinions des Développeurs.
+
+Le Chef du Projet devrait éviter de trop souligner son propre point de vue quand il s'agit de prendre des décisions qui relèvent de ses attributions de Chef.
+
+1~ Comité Technique
+
+2~ Pouvoirs
+
+Le Comité Technique peut :
+
+# Décider sur n'importe quel sujet concernant les règles techniques.
+
+Cela inclut le contenu des manuels de règles techniques, des documents de référence pour les développeurs, des paquets exemples et le comportement des outils non expérimentaux de création de paquets (dans chaque cas, le responsable du logiciel concerné ou de la documentation prend les décisions initialement, cependant ; voir 6.3(5)).
+
+# Décider sur n'importe quel sujet technique où les juridictions des Développeurs se recouvrent.
+
+Dans les cas où les Développeurs ont besoin d'implémenter des règles techniques compatibles ou des décisions (par exemple, s'ils ne sont pas d'accord sur les priorités de paquets en conflit, ou pour attribuer la propriété d'un nom de commande, ou pour déterminer quel paquet est responsable d'un bogue que les deux responsables reconnaissent être un bogue, ou pour désigner le responsable d'un paquet), le Comité Technique peut décider sur le sujet.
+
+# Prendre une décision quand on le lui demande.
+
+Une personne ou un corps peut déléguer une décision de son ressort au Comité Technique, ou chercher conseil auprès de lui.
+
+# Outrepasser un Développeur (demande une majorité de 3 contre 1).
+
+Le Comité Technique peut demander à un Développeur de choisir une solution technique particulière même si le Développeur ne le souhaite pas ; cela demande une majorité de 3 contre 1. Par exemple, le Comité peut décider qu'une complainte faite par une personne soumettant un bogue est justifiée et que la solution proposée par celui qui soumet le bogue devrait être implémentée.
+
+# Offrir conseil.
+
+Le Comité Technique peut faire des annonces formelles à propos de ses vues sur n'importe quel sujet. Les membres individuels peuvent bien sûr faire des déclarations informelles à propos de leurs vues et à propos des vues probables du comité.
+
+# Ensemble avec le Chef du Projet, nommer de nouveaux membres en son sein ou en retirer. (Voir §6.2.)
+
+# Nommer le Président du Comité Technique.
+
+Le Président est élu par le Comité à partir de ses membres. Tous les membres du Comité sont automatiquement nommés ; le Comité vote en commençant une semaine avant que le poste ne devienne vacant (ou immédiatement, si c'est déjà trop tard). Les membres peuvent voter par acclamation publique pour n'importe quel membre du Comité, y compris eux-même ; il n'y a pas de choix par défaut. Le vote se termine lorsque tous les membres ont voté ou quand la période du scrutin se termine. Le résultat est déterminé en utilisant la méthode décrite dans la section A.6 de la Procédure standard de résolution.
+
+# Le Président peut représenter le Chef, ensemble avec le Secrétaire.
+
+Comme détaillé dans §7.1(2), le Président du Comité Technique et le Secrétaire du Projet peuvent ensemble représenter le Chef s'il n'y a pas de Chef.
+
+2~ Composition
+
+# Le Comité Technique est constitué d'au plus 8 Développeurs, et devrait normalement avoir au moins 4 membres.
+
+# Quand il y a moins de 8 membres le Comité Technique peut recommander un nouveau membre (ou plus) au Chef du Projet, qui peut choisir (individuellement) de les nommer ou pas.
+
+# Quand il y a 5 membres ou moins, le Comité Technique peut nommer de nouveaux membres jusqu'à ce que le nombre de membres atteigne 6.
+
+# Quand il y a eu 5 membres ou moins pendant au moins une semaine, le Chef du Projet peut nommer de nouveaux membres jusqu'à ce que le nombre de membres atteigne 6, à intervalles d'au moins une semaine par nomination.
+
+# Si le Comité Technique et le Chef du Projet sont d'accord ils peuvent retirer ou remplacer un membre existant du Comité Technique.
+
+2~ Procédure
+
+# Le Comité Technique utilise la Procédure Standard de Résolution.
+
+Une proposition de résolution ou un amendement peut être proposé par n'importe quel membre du Comité Technique. Il n'y a pas de période de discussion minimum ; la période de vote dure jusqu'à une semaine, ou jusqu'à ce que le résultat ne fasse plus de doute. Les membres peuvent modifier leurs votes. Il y a un quorum de deux.
+
+# Détails concernant le vote.
+
+Le Président a une voix discriminante. Lorsque le Comité Technique vote pour outrepasser un Développeur qui est aussi un membre du Comité, ce membre ne peut pas voter (sauf s'il s'agit du Président, auquel cas il peut utiliser seulement sa voix discriminante).
+
+# Discussion publique et prise de décision.
+
+Les discussions, propositions de résolutions et amendements, et votes par les membres du Comité, sont rendus publics sur la liste de discussion du Comité Technique. Il n'y a pas de secrétariat séparé pour le Comité.
+
+# Confidentialité des nominations.
+
+Le Comité Technique peut rendre confidentielles les discussions par courrier électronique privé ou par liste de diffusion privée ou d'autres moyens afin de discuter les nominations au Comité. Cependant, les votes des nominations doivent être publics.
+
+# Pas de travail de conception détaillé.
+
+Le Comité Technique ne s'engage pas dans la conception de nouvelles propositions et de nouvelles règles. Ce travail de conception doit être mené par les individus de manière privée ou ensemble et discuté dans des forums techniques ordinaires de conception et de choix d'implémentation.
+
+Le Comité Technique se restreint à choisir ou adopter des compromis entre les solutions et décisions qui ont été proposées et suffisamment bien discutées ailleurs.
+
+Les membres individuels du Comité Technique peuvent bien sûr participer en leur propre nom à tous les aspects du travail de conception et de choix d'implémentation.
+
+# Le Comité Technique prend les décisions uniquement en dernier ressort.
+
+Le Comité Technique ne prend pas de décision technique tant que des efforts de résolution par consensus n'ont pas été menés et n'ont pas échoué sauf s'il lui a été demandé de prendre la décision par la personne ou le corps qui en serait normalement responsable.
+
+1~ Le Secrétaire du Projet
+
+2~ Pouvoirs
+
+Le Secrétaire :
+
+# Reçoit les votes des Développeurs, et détermine le nombre et l'identité des Développeurs, quand c'est requis par la constitution.
+
+# Peut représenter le Chef, avec le Président du Comité Technique.
+
+S'il n'y a pas de Chef du Projet alors le Président du Comité Technique et le Secrétaire du Projet peuvent par accord mutuel prendre des décisions s'ils considèrent comme impératif de le faire.
+
+# Résout les divergences d'interprétation de la constitution.
+
+# Peut déléguer une part ou toute son autorité à quelqu'un d'autre, ou retirer une telle délégation à tout moment.
+
+2~ Nomination
+
+Le Secrétaire du Projet est nommé par le Chef du Projet et le Secrétaire du Projet courant.
+
+Si le Chef du Projet et le Secrétaire du Projet courant ne peuvent se mettre d'accord sur une nouvelle nomination, ils doivent demander au conseil d'administration de SPI (voir §9.1.) de nommer un Secrétaire.
+
+S'il n'y a pas de Secrétaire du Projet ou si le Secrétaire courant n'est pas disponible et n'a pas délégué d'autorité pour une décision alors la décision peut être faite ou déléguée par le Président du Comité Technique, en tant que Secrétaire en Acte.
+
+La durée du mandat de Secrétaire du Projet est de un an, à la suite duquel lui ou un autre Secrétaire doit être (re)nommé.
+
+2~ Procédure
+
+Le Secrétaire du Projet devrait prendre des décisions justes et raisonnables, et de préférence en accord avec le consensus des Développeurs.
+
+Quand ils agissent ensemble pour représenter un Chef du Projet absent, le Président du Comité Technique et le Secrétaire du Projet devraient prendre des décisions seulement quand c'est absolument nécessaire et seulement en accord avec le consensus des Développeurs.
+
+1~ Les Délégués du Chef du Projet
+
+2~ Pouvoirs
+
+Les Délégués du Chef du Projet :
+
+# ont les pouvoirs qui leurs sont délégués par le Chef du Projet ;
+
+# peuvent prendre certaines décisions que le Chef ne peut prendre directement, y compris approuver ou expulser des Développeurs ou désigner des gens comme Développeurs qui ne maintiennent pas de paquets. C'est pour éviter la concentration des pouvoirs, particulièrement au sujet de la qualité de Développeur, dans les mains du Chef du Projet.
+
+2~ Nomination
+
+Les Délégués sont nommés par le Chef du Projet et peuvent être remplacés par le Chef à sa discrétion. Le Chef du Projet ne peut rendre le poste de Délégué conditionnel à des décisions particulières du Délégué, ni outrepasser une décision prise par un Délégué une fois prise.
+
+2~ Procédure
+
+Les Délégués peuvent prendre les décisions selon leur convenance, mais devraient essayer d'implémenter de bonnes décisions techniques et/ou suivre l'opinion consensuelle.
+
+1~ Software in the Public Interest
+
+SPI et Debian sont des organisations séparées qui partagent certains buts. Debian remercie SPI pour le support légal offert par cette organisation.Les Développeurs Debian sont des membres courants de SPI de par leur status de Développeurs.
+
+2~ Autorité
+
+# SPI n'a pas d'autorité concernant les décisions techniques ou non techniques de Debian, excepté que toute décision de Debian concernant tous les biens gardés par SPI nécessite que SPI agisse en dehors de son autorité légale, et que la constitution de Debian peut occasionnellement utiliser SPI comme un corps de décision en dernier ressort.
+
+# Debian ne revendique aucune autorité sur SPI autre que l'utilisation de certains biens de SPI, comme décrit ci dessous, bien que les Développeurs Debian peuvent recevoir des responsabilité à l'intérieur de SPI suivant les règles de SPI.
+
+# Les Développeurs Debian ne sont pas des agents ou des employés ni de SPI, ni les uns des autres, ni de personnes ayant des responsabilités dans le Projet Debian. Une personne agissant en tant que Développeur le fait en tant qu'individu, de son propre chef.
+
+2~ Gestion des biens pour les besoins de Debian
+
+Comme Debian n'a pas d'autorité légale pour garder de l'argent ou des biens, tous les dons pour le Projet Debian doivent être faits à SPI, qui gère ce type d'affaires.
+
+SPI a pris les engagements suivants :
+
+# SPI gardera l'argent, les marques commerciales et les autres biens tangibles et intangibles et gérera des affaires pour les besoins de Debian ;
+
+# Ces biens seront comptabilisés séparément et gardés en commun pour ces besoins, les décisions les concernant seront prises par Debian et SPI conformément à cette section ;
+
+# SPI n'utilisera pas et ne disposera pas de ces biens gardés en commun pour Debian sans l'approbation de Debian, qui peut être fournie par le Chef du Projet ou par Résolution Générale des Développeurs ;
+
+# SPI pourra utiliser et disposer de ces biens gardés en commun pour Debian quand cela lui sera demandé par le Chef du Projet ;
+
+# SPI utilisera et disposera de ces biens gardés en commun pour Debian quand cela lui sera demandé par Résolution Générale des Développeurs, pourvu que cela soit compatible avec l'autorité légale de SPI ;
+
+# SPI informera les Développeurs par courrier électronique sur la liste de diffusion du Projet Debian quand il utilisera ou disposera des biens gardés en commun pour Debian.
+
+1~a A. Procédure de Résolution Standard
+
+Ces règles s'appliquent aux prises de décision communes par comités et plébiscites, là où cela est indiqué plus haut.
+
+2~a1a A.1. Proposition
+
+La procédure formelle commence quand un projet de résolution est proposé et soutenu, comme il est requis.
+
+2~a1a A.1. Discussion et Amendements
+
+# Après la proposition, la résolution peut être discutée. Les amendements peuvent être rendus formels en étant proposés et soutenus conformément aux exigences d'une nouvelle résolution, ou directement par celui qui a proposé la résolution originale.
+
+# Un amendement formel peut être accepté par celui qui propose la résolution, dans ce cas la proposition de résolution formelle est immédiatement modifiée pour s'y accorder.
+
+# Si un amendement formel n'est pas accepté, ou si l'un de ceux qui soutiennent la résolution n'est pas d'accord avec l'acceptation d'un amendement formel par celui qui propose la résolution, l'amendement reste un amendement et sera mis au vote.
+
+# Si un amendement accepté par celui qui a originellement proposé la résolution n'est pas du goût d'autres développeurs, ils peuvent proposer un autre amendement pour inverser les changements précédents (de même, ils doivent satisfaire aux exigences relatives à celui qui le propose et ceux qui le soutiennent).
+
+# Celui qui propose la résolution ou la résolution elle-même peuvent suggérer des modifications à la rédaction des amendements ; ils prennent effet si celui qui propose un amendement est d'accord et si aucun de ceux qui le soutiennent ne s'y oppose. Dans ce cas les amendements modifiés seront votés à la place des amendements originaux.
+
+# Celui qui propose une résolution peut faire des modifications pour corriger des erreurs mineures (par exemple, des erreurs typographiques ou des inconsistances) ou changements qui n'en modifient pas la signification, pourvu que personne ne s'y oppose dans les 24 heures. Dans ce cas la période de discussion minimum n'est pas recommencée.
+
+2~a2 A.2. Appel à voter
+
+# Celui qui propose ou l'un de ceux qui soutiennent une motion ou un amendement peuvent appeler à voter, pourvu que la période de discussion minimum (s'il y en a) soit terminée.
+
+# Celui qui propose ou l'un de ceux qui soutiennent une résolution peuvent appeler à voter sur cette résolution et tous les amendements liés.
+
+# La personne qui appelle à voter déclare ce qu'elle croît devoir être la formulation de la résolution et des amendements liés, et en conséquence ce que la forme du bulletin doit être. Cependant, la décision finale sur la forme du ou des bulletins est celle du Secrétaire - voir 7.1(1), 7.1(3) et A.3(4).
+
+# La période de discussion minimum est comptée à partir du moment où le dernier amendement formel a été accepté, ou à partir du moment où l'entière résolution a été proposée si aucun amendement n'a été proposé et accepté.
+
+2~a3 A.3. Procédure de vote
+
+# Chaque résolution et les amendements qui lui sont liés sont soumis aux votes en un seul scrutin qui contient une option pour la résolution originale, pour chaque amendement, et pour l'option par défaut (quand elle s'applique).
+
+# L'option par défaut ne doit nécessiter aucune supermajorité. Les options qui ne nécessitent pas de supermajorité ont besoin d'une majorité de 1:1 pour être adoptés.
+
+# Les votes sont comptabilisés suivant les règles de A.6. L'option par défaut est « Further Discussion » (Discussion prolongée), sauf en cas de spécification contraire.
+
+# En cas de doutes le Secrétaire du Projet devra décider sur les questions de procédure.
+
+2~a4 A.4. Retrait des résolutions et des amendements non encore acceptés
+
+Celui qui propose une résolution ou un amendement non encore accepté peut le retirer. Dans ce cas certains peuvent vouloir le (ou la) garder, auquel cas la première personne qui souhaite le (ou la) garder devient celui qui le (ou la) propose et les autres soutiennent alors si ce n'est pas déjà le cas.
+
+Ceux qui soutiennent une résolution ou un amendement (sauf s'il a été accepté) peuvent se retirer.
+
+Si le retrait de celui qui propose et/ou de ceux qui soutiennent implique qu'une résolution ou un amendement ne soit plus proposée ou n'ai pas assez de personne qui la soutienne elle ne sera pas voté sauf si cela est rectifié avant que la résolution expire.
+
+2~a5 A.5. Expiration
+
+Si une résolution proposée n'a pas été discutée, amendée, votée ou traitée d'une façon ou d'une autre pendant 4 semaines, le Secrétaire peut décréter que la résolution est retirée. Si aucun de ceux qui soutiennent l'une des propositions ne manifeste son désaccord pendant une semaine, la résolution est retirée.
+
+Le Secrétaire peut aussi suggérer des façons de procéder, si besoin.
+
+2~a6 A.6. Comptabilisation des Votes
+
+# Chaque bulletin de vote classe les options soumises au vote. Il n'est pas nécessaire que toutes les options apparaissent dans le classement. Les options apparaissant dans le classement sont considérées comme préférées à toutes celles qui n'y apparaissent pas. Les votants peuvent classer à égalité plusieurs options. Les options non classées sont considérées comme étant à égalité les unes avec les autres. Les détails sur la façon dont les bulletins doivent être remplis seront contenus dans l'appel à voter.
+
+# Si le scrutin nécessite un quorum R, toute option autre que celle par défaut, qui ne reçoit pas au moins R votes qui la classent au dessus de l'option par défaut, est ignorée.
+
+# Toute option (autre que celle par défaut), qui ne bat pas l'option par défaut avec un rapport au moins égal à celui de la majorité requise, est ignorée.
+
+_# Étant donné deux options A et B, V(A,B) est le nombre de votants préférant l'option A à l'option B.
+
+_# Une option A bat l'option par défaut D avec un rapport de majorité N, si V(A,D) est strictement supérieur à N * V(D,A).
+
+_# Si une supermajorité de S:1 est nécessaire pour A, son rapport de majorité est S; sinon, il est égal à 1.
+
+# À partir de la liste des options non ignorées, nous générons une liste des vainqueurs deux à deux.
+
+_# Une option A bat une option B, si V(A,B) est strictement supérieur à V(B,A).
+
+# À partir de la liste des vainqueurs [non-ignorés] deux à deux, nous générons un ensemble des vainqueurs transitifs.
+
+_# Une option A bat transitivement une option C si A bat C ou s'il y a une autre option B telle que A bat B ET B bat transitivement C.
+
+# Nous construisons l'ensemble de Schwartz à partir de l'ensemble des vainqueurs transitif.
+
+_# Une option A est dans l'ensemble de Schwartz si pour toutes les options B, soit A bat transitivement B, soit B ne bat pas transitivement A.
+
+# S'il y a des options qui en battent d'autres dans l'ensemble de Schwartz, nous sortons les plus faibles des vainqueurs de la liste des vainqueurs deux à deux, et retournons à l'étape 5.
+
+_# Une victoire (A,X) est plus faible qu'une victoire (B,Y) si V(A,X) est inférieur à V(B,Y). Et de plus, (A,X) est plus faible que (B,Y) si V(A,X) est égal à V(B,Y) et V(X,A) est plus grand que V(Y,B).
+
+_# Une plus faible victoire est une victoire qui n'a pas de victoire plus faible qu'elle. Il peut y avoir plusieurs victoires de ce type.
+
+# S'il n'y a pas de plus faible dans l'ensemble de Schwartz set, alors le vainqueur est choisi dans l'ensemble de Schwartz set. S'il n'y a qu'une seule option, c'est le vainqueur. S'il y en a plusieurs, le votant ayant un vote discriminant choisi l'option qui gagne parmi celles-ci.
+
+Note : Les options que les votants classent au dessus de l'option par défaut sont celles qu'ils trouvent acceptables. Les options classées en dessous de l'option par défaut sont les options qu'ils trouvent inacceptables.
+
+Quand la Procédure de Résolution Standard est utilisée, le texte qui y fait référence doit spécifier ce qui est suffisant pour qu'une proposition de résolution soit proposée et/ou soutenue, ce qu'est la période de discussion minimum, et ce qu'est la période de vote. Il doit aussi spécifier quelle supermajorité et/ou le quorum (et le choix par défaut) à utiliser.
+
+1~b B. Utilisation du langage et typographie
+
+Le présent ou le futur de l'indicatif (« est » ou « sera », par exemple) signifie que l'affirmation est une règle dans cette constitution. Le verbe « Pouvoir » indique que la personne ou le corps a le choix. Le verbe « Devoir » au conditionnel indique que cela serait considéré comme une bonne chose si ce qui prescrit était respecté, mais cela n'est pas obligatoire. Le texte marqué comme une citation, comme celui ci, se veut simplement raisonnable et ne fait pas partie de la constitution. Il peut être utilisé seulement pour aider à l'interprétation en cas de doute.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/fr/debian_social_contract_v1.1.sst b/debian/data/doc/sisu/markup-samples/samples/v3/fr/debian_social_contract_v1.1.sst
new file mode 100644
index 00000000..deb46db2
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/fr/debian_social_contract_v1.1.sst
@@ -0,0 +1,136 @@
+% SiSU 2.0
+
+@title: Le contrat social Debian
+ :subtitle: Debian Social Contract (v1.1)
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:policy:social contract;GNU/Linux:debian:social contract;language:French
+
+@date:
+ :created: 1997-07-05
+ :issued: 1997-07-05
+ :valid: 2004-04-26
+ :available: 2004-04-26
+ :modified: 2004-04-26
+ :publisher: 2004-04-26
+
+@language:
+ :document: French
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.da.html <br>« Debian » et le logo Debian sont des marques déposées appartenant à Software in the Public Interest, Inc.<br>En cas de litige, seule la version originale de cette page a valeur au regard de la loi http://www.debian.org/license.en.html.
+ :license: Ce matériel ne peut être distribué que conformément aux termes et conditions présentés dans la Licence de Publication Ouverte (Open Publication License), Draft v.1.0 ou suivantes. (Vous pouvez lire notre copie locale http://www.debian.org/opl, dont la version la plus récente est généralement disponible à http://www.opencontent.org/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/social_contract
+ {Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
+
+@make:
+ :breaks: new=C; break=1
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Le contrat social Debian
+
+1~pre [Prefix]-#
+
+Version 1.1 ratifiée le 26 avril 2004. Remplace la version 1.0 ratifiée le 5 juillet 1997.
+
+Le projet Debian, concepteur du système GNU/Linux Debian, a créé le contrat social de Debian. La partie consacrée aux principes du logiciel libre selon Debian (Debian Free Software Guidelines, ou DFSG), initialement conçue comme un ensemble de principes auxquels nous tenons fermement, a été adoptée par la communauté du logiciel libre comme base pour la définition de l'informatique libre (Open Source Definition).
+
+1~ « Contrat social » avec la communauté des logiciels libres
+
+2~ 1. Debian demeurera totalement libre.
+
+Nous fournissons les principes que nous utilisons pour déterminer si un travail est « libre » dans le document intitulé « Principes du logiciel libre selon Debian ». Nous promettons que le système Debian et tous ses composants seront libres selon ces principes. Nous aiderons les personnes qui créent et utilisent à la fois des travaux libres et non libres sur Debian. Nous ne rendrons pas le système dépendant d'un composant non libre.
+
+2~ 2. Nous donnerons nos travaux à la communauté des logiciels libres.
+
+Lorsque nous écrirons de nouveaux composants du système Debian, nous les publierons sous une licence compatible avec les principes du logiciel libre selon Debian. Nous ferons le meilleur système possible, afin que les travaux libres soient largement distribués et utilisés. Nous signalerons les corrections de bogues, les améliorations, les requêtes des utilisateurs, etc. aux auteurs des travaux originels inclus dans notre système.
+
+2~ 3. Nous ne cacherons pas les problèmes.
+
+Toute notre base de données sur les rapports de bogue sera consultable à tous moments par tous. Les rapports que les personnes remplissent en ligne seront immédiatement visibles par les autres.
+
+2~ 4. Nos priorités sont nos utilisateurs et les logiciels libres.
+
+Les besoins de nos utilisateurs et de la communauté des logiciels libres nous guideront. Nous placerons leurs intérêts en tête de nos priorités. Nous assumerons les besoins de nos utilisateurs dans de nombreux types d'environnements informatiques différents. Nous ne nous opposerons pas aux travaux non libres prévus pour fonctionner sur les systèmes Debian. Nous permettrons que d'autres créent des distributions contenant conjointement des logiciels Debian et d'autres travaux, et ceci sans réclamer aucune rétribution. Pour servir ces objectifs, nous fournirons un système intégré de composants de grande qualité sans restrictions légales qui empêcheraient ces types d'usage.
+
+2~ 5. Travaux non conformes à nos standards sur les logiciels libres.
+
+Nous reconnaissons que certains de nos utilisateurs demandent à pouvoir utiliser des travaux qui ne sont pas conformes aux principes du logiciel libre selon Debian. Pour ces travaux, nous avons créé des sections contrib (« contributions ») et non-free (« non libre ») dans notre archive. Les paquets dans ces sections ne font pas partie du système Debian, bien qu'ils aient été configurés afin d'être utilisés avec Debian. Nous encourageons les fabricants de CD à lire les licences des paquets en question afin de déterminer s'ils peuvent les distribuer dans leurs CD. Ainsi, bien que les travaux non libres ne fassent pas partie de Debian, nous assumons leur utilisation et fournissons une infrastructure (à l'image de notre système de suivi des bogues et de nos listes de diffusion) pour des paquets non libres.
+
+1~ Les principes du logiciel libre selon Debian
+
+2~ 1. Redistribution libre et gratuite.
+
+La licence d'un composant de Debian ne doit pas empêcher quiconque de vendre ou donner le logiciel sous forme de composant d'un ensemble (distribution) constitué de programmes provenant de différentes sources. La licence ne doit requérir ni redevance ni rétribution sur une telle vente.
+
+2~ 2. Code source.
+
+Le programme doit inclure le code source, et la diffusion sous forme de code source comme sous forme de programme compilé doit être autorisée.
+
+2~ 3. Applications dérivées.
+
+La licence doit permettre les modifications et les applications dérivées, et elle doit permettre à celles-ci d'être distribuées sous les mêmes termes que ceux de la licence du logiciel original.
+
+2~ 4. Intégrité du code source de l'auteur.
+
+La licence peut défendre de distribuer le code source modifié seulement si elle autorise la distribution avec le code source de fichiers correctifs destinés à modifier le programme au moment de la construction. La licence doit autoriser explicitement la distribution de logiciels créés à partir de code source modifié. Elle peut exiger que les applications dérivées portent un nom ou un numéro de version différent de ceux du logiciel original (c'est un compromis ; le groupe Debian encourage tous les auteurs à ne restreindre en aucune manière les modifications des fichiers, source ou binaire).
+
+2~ 5. Aucune discrimination de personne ou de groupe.
+
+La licence ne doit discriminer aucune personne ou groupe de personnes.
+
+2~ 6. Aucune discrimination de champ d'application.
+
+La licence ne doit pas défendre d'utiliser le logiciel dans un champ d'application particulier. Par exemple, elle ne doit pas défendre l'utilisation du logiciel dans une entreprise ou pour la recherche génétique.
+
+2~ 7. Distribution de licence.
+
+Les droits attachés au programme doivent s'appliquer à tous ceux à qui il est distribué sans obligation pour aucune de ces parties de se conformer à une autre licence.
+
+2~ 8. La licence ne doit pas être spécifique à Debian.
+
+Les droits attachés au programme ne doivent pas dépendre du fait qu'il fasse partie du système Debian. Si le programme est extrait de Debian et est utilisé et distribué sans Debian mais sous les termes de sa propre licence, toutes les parties auxquelles il est redistribué doivent jouir des même droits que ceux accordés avec le système Debian.
+
+2~ 9. La licence ne doit pas contaminer d'autres logiciels.
+
+La licence ne doit pas placer de restrictions sur d'autres logiciels distribués avec le logiciel licencié. Par exemple, la licence ne doit pas exiger que tous les autres programmes distribués sur le même support doivent être des logiciels libres.
+
+2~ 10. Exemples de licence.
+
+Les licences « GPL », « BSD » et « Artistic » sont des exemples de licences que nous considérons « libres ».
+
+L'idée de rédiger nos « principes du logiciel libre » fut suggérée par Ean Schuessler. Bruce Perens écrivit la première ébauche de ce document et le perfectionna d'après les commentaires des développeurs de Debian recueillis à l'occasion d'une conférence par courriels qui s'est déroulé pendant tout le mois de juin 1997. Il fut ensuite accepté comme faisant partie intégrante de la charte du projet Debian.
+
+Plus tard, Bruce Perens retira toute référence au projet Debian des DFSG pour en faire la « Définition de l'Open Source ».
+
+D'autres organisations peuvent utiliser ce document. Si vous le faites, veuillez faire référence au projet Debian.
+
+%% SiSU markup sample Notes:
+% SiSU http://www.jus.uio.no/sisu
+% SiSU markup for 0.16 and later:
+% 0.20.4 header 0~links
+% 0.22 may drop image dimensions (rmagick)
+% 0.23 utf-8 ß
+% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
+% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
+% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
+% markup in this document is 0.38, (rad) experimental
diff --git a/debian/data/doc/sisu/markup-samples/samples/v3/it/debian_social_contract_v1.1.sst b/debian/data/doc/sisu/markup-samples/samples/v3/it/debian_social_contract_v1.1.sst
new file mode 100644
index 00000000..cd96e159
--- /dev/null
+++ b/debian/data/doc/sisu/markup-samples/samples/v3/it/debian_social_contract_v1.1.sst
@@ -0,0 +1,127 @@
+% SiSU 2.0
+
+@title: Contrato social de Debian
+ :subtitle: Debian Social Contract (v1.1)
+
+@creator:
+ :author: Debian Project
+
+@classify:
+ :type: information
+ :subject: debian policy
+ :topic_register: debian:policy:social contract;GNU/Linux:debian:social contract;language:Italian
+
+@date:
+ :published: 2004-04-26
+ :created: 1997-07-05
+ :issued: 1997-07-05
+ :valid: 2004-04-26
+ :available: 2004-04-26
+ :modified: 2004-04-26
+
+@language:
+ :document: Italian
+ :original: English
+
+@rights:
+ :copyright: Copyright © 1997-2006 Software in the Public Interest, Inc., http://www.spi-inc.org/ P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.debian.org/license.it.html <br>“Debian” e il Logo Debian http://www.debian.org/logos/ sono trademark di Software in the Public Interest, Inc.<br>N.d.T.: Questa è una traduzione della licenza originale in inglese. In tutti in casi in cui il significato della traduzione differisca da quello dell’originale, la versione corretta è da considerarsi quella originale http://www.debian.org/license.en.html.
+ :license: Questo materiale può essere distribuito solo ai termini e sotto le consizioni poste nel “Open Publication License”, Bozza v1.0 o successiva (si può leggere la nostra copia http://www.debian.org/opl o l’ultima versione normalmente disponibile presso http://www.opencontent.org/openpub/ ).
+
+@links:
+ {Authoritative Source Document}http://www.debian.org/social_contract
+ {Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html
+ {About Debian}http://www.debian.org/intro/about
+ {News}http://www.debian.org/News/
+ {Getting Debian}http://www.debian.org/distrib/
+ {Support}http://www.debian.org/support
+ {Developer's Corner}http://www.debian.org/devel/
+ {Sitemap}http://www.debian.org/sitemap
+ {Search}http://search.debian.org/
+
+@notes:
+ :prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
+
+@make:
+ :breaks: new=:C; break=1
+ :skin: skin_debian
+ :bold: Debian; DPL
+
+:A~ Il Contratto Sociale Debian
+
+1~pre [Prefix]-#
+
+La versione 1.1 approvata il 26 aprile 2004 che sostituisce la versione 1.0 approvata il 5 luglio 1997.
+
+Debian, i produttori del sistema Debian GNU/Linux, ha creato il Contratto Sociale Debian (Debian Social Contract). Le Linee Guida Debian per il Software Libero (Debian Free Software Guidelines - DFSG) che sono parte del contratto, inizialmente pensate come un insieme di punti che noi tutti sottoscriviamo, sono state adottate dalla comunità del software libero come base per l'Open Source Definition.
+
+1~ Contratto Sociale con la Comunità Free Software
+
+2~ 1. Debian rimarrà libera al 100%
+
+Forniamo le linee guida che usiamo per determinare se un'opera sia "libera" nel documento intitolato "The Debian Free Software Guidelines". Promettiamo che il sistema Debian e tutte le sue componenti rimarranno liberi in accordo con le citate linee guida. Supporteremo le persone che creino o usino in Debian opere sia libere che non libere. Non renderemo mai il sistema dipendente da un componente non libero.
+
+2~ 2. Renderemo alla Comunità Free Software
+
+Quando scriviamo nuovi componenti del sistema Debian, li rilasceremo con una licenza che rispetti le Debian Free Software Guidelines. Realizzeremo il sistema migliore che potremo, cosicché le opere libere siano usate e distribuite il più possibile. Comunicheremo cose come bug fix, migliorie e richieste degli utenti agli autori "upstream" delle opere incluse nel nostro sistema.
+
+2~ 3. Non nasconderemo i problemi
+
+Manterremo sempre il nostro intero bug report database aperto alla pubblica lettura. I rapporti che le persone invieranno online saranno prontamente resi visibili a tutti.
+
+2~ 4. Le nostre priorità sono gli utenti ed il software libero
+
+Ci faremo guidare dai bisogni dei nostri utenti e della comunità del software libero. Metteremo al primo posto i loro interessi. Supporteremo le necessità dei nostri utenti di operare in molti diversi tipi di ambienti di calcolo. Non ci opporremo alle opere non libere che siano state pensate per l'uso in sistemi Debian e non richiederemo compensi a chi crea o usa queste opere. Permetteremo ad altri di creare distribuzioni contenenti sia il sistema Debian che altre opere, senza richiedere compensi. Per raggiungere questi scopi, forniremo un sistema integrato di materiali di alta qualità senza alcuna restrizione legale che limiti qualsiasi uso del sistema.
+
+2~ 5. Opere che non rispettano i nostri standard free software
+
+Ci rendiamo conto che alcuni dei nostri utenti richiedono di usare opere non conformi alle Debian Free Software Guidelines. Abbiamo creato le aree "contrib" e "non-free" nel nostro archivi per queste opere. I pacchetti in queste aree non fanno parte del sistema Debian, sebbene siano stati configurati per l'uso con Debian. Invitiamo i realizzatori di CD a leggere le licenze dei pacchetti in queste aree per determinare se possono distribuire i pacchetti sui loro CD. Inoltre, anche se le opere non libere non fanno parte di Debian, supporteremo il loro uso e forniremo infrastrutture per i pacchetti non liberi (come il nostro bug tracking system e le mailing list).
+
+1~ Le Linee Guida Debian per il Software Libero (Debian Free Software Guidelines - DFSG)
+
+2~ 1. Libera ridistribuzione
+
+La licenza di un componente Debian non può porre restrizioni a nessuno per la vendita o la cessione del software come componente di una distribuzione software aggregata di programmi proveniente da fonti diverse. La licenza non può richiedere royalty o altri pagamenti per la vendita.
+
+2~ 2. Codice sorgente
+
+Il programma deve includere il codice sorgente e deve permettere la distribuzione sia come codice sorgente che in forma compilata.
+
+2~ 3. Lavori derivati
+
+La licenza deve permettere modifiche e lavori derivati e deve permettere la loro distribuzione con i medesimi termini della licenza del software originale.
+
+2~ 4. Integrità del codice sorgente dell'autore
+
+La licenza può porre restrizioni sulla distribuzione di codice sorgente modificato _solo_ se permette la distribuzione di "file patch" insieme al codice sorgente con lo scopo di modificare il programma durante la compilazione. La licenza deve esplicitamente permettere la distribuzione di software compilato con codice sorgente modificato. La licenza può richiedere che i lavori derivati abbiano un nome o un numero di versione diversi da quelli del software originali. (Questo è un compromesso. Il gruppo Debian invita tutti gli autori a non impedire che file, sorgenti o binari possano essere modificati.)
+
+2~ 5. Nessuna discriminazione di persone o gruppi
+
+La licenza non può discriminare nessuna persona o gruppo di persone.
+
+2~ 6. Nessuna discriminazione nei campi di impiego
+
+La licenza non può porre restrizioni all'utilizzo del programma in uno specifico campo di impiego. Per esempio, non può porre restrizioni all'uso commerciale o nella ricerca genetica.
+
+2~ 7. Distribuzione della licenza
+
+I diritti applicati al programma devono essere applicabili a chiunque riceva il programma senza il bisogno di utilizzare licenze addizionali di terze parti.
+
+2~ 8. La licenza non può essere specifica per Debian
+
+I diritti applicati al programma non possono dipendere dal fatto che esso sia parte di un sistema Debian. Se il programma è estratto da Debian e usato o distribuito senza Debian ma ottemperando ai termini della licenza, tutte le parti alle quali il programma è ridistribuito dovrebbero avere gli stessi diritti di coloro che lo ricevono con il sistema Debian.
+
+2~ 9. La licenza non deve contaminare altro software
+
+La licenza non può porre restrizioni ad altro software che sia distribuito insieme al software concesso in licenza. Per esempio, la licenza non può richiedere che tutti gli altri programmi distribuiti con lo stesso supporto debbano essere software libero.
+
+2~ 10. Esempi di licenze
+
+Le licenze "GPL", "BSD" e "Artistic" sono esempi di licenze che consideriamo "libere".
+
+I concetti enunciati nel nostro "contratto sociale con la comunità del software libero" furono proposti da Ean Schuessler. Questo documento fu abbozzato da Bruce Perens, rifinito da altri sviluppatori Debian durante una conferenza via posta elettronica durata un mese (Giugno 1997) ed infine approvata come pubblica linea di condotta del Progetto Debian.
+
+Bruce Perens in seguito ha rimosso i riferimenti specifici a Debian dalle Linee Guida Debian per il Free Software per creare “L'Open Source Definition”.
+
+Altre organizzazioni possono derivare da questo documento. Per favore, se lo si fa, se ne dia credito al progetto Debian.
+
+Ritorna alla pagina principale del Progetto Debian.
diff --git a/debian/manpages/sisu-complete.7 b/debian/manpages/sisu-complete.7
new file mode 100644
index 00000000..47576c9f
--- /dev/null
+++ b/debian/manpages/sisu-complete.7
@@ -0,0 +1,32 @@
+.TH SISU\-COMPLETE 7 2010\-06\-19 2.5.1 SiSU
+
+.SH NAME
+\fBSiSU\fR \- Structured information, Serialized Units \- a document publishing system, complete dependency package
+
+.SH DESCRIPTION
+\fBSiSU\fR is a lightweight markup based document structuring, publishing and search framework for document collections.
+.PP
+The sisu\-complete package installs \fBSiSU\fR and related packages that enable sisu to produce pdf and to populate PostgreSQL and sqlite databases.
+
+.SH SEE ALSO
+\fIsisu\fR(1),
+.br
+\fIsisu\fR(8).
+.br
+\fIsisu_termsheet\fR(1).
+.br
+\fIsisu_vim\fR(7),
+.br
+\fIsisu_webrick\fR(1),
+.PP
+\fIsisu\-pdf\fR(7),
+.br
+\fIsisu\-postgresql\fR(7),
+.br
+\fIsisu\-sqlite\fR(7).
+
+.SH HOMEPAGE
+More information about \fBSiSU\fR can be found at <\fIhttp://www.jus.uio.no/sisu/\fR>.
+
+.SH AUTHOR
+\fBSiSU\fR was written by Ralph Amissah <\fIralph@amissah.com\fR>.
diff --git a/debian/manpages/sisu-pdf.7 b/debian/manpages/sisu-pdf.7
new file mode 100644
index 00000000..17117191
--- /dev/null
+++ b/debian/manpages/sisu-pdf.7
@@ -0,0 +1,32 @@
+.TH SISU\-PDF 7 2010\-06\-19 2.5.1 SiSU
+
+.SH NAME
+\fBSiSU\fR \- Structured information, Serialized Units \- a document publishing system, complete dependency package
+
+.SH DESCRIPTION
+\fBSiSU\fR is a lightweight markup based document structuring, publishing and search framework for document collections.
+.PP
+The sisu\-pdf package enables the conversion of \fBSiSU\fR LaTeX output to pdf.
+
+.SH SEE ALSO
+\fIsisu\fR(1),
+.br
+\fIsisu\fR(8).
+.br
+\fIsisu_termsheet\fR(1).
+.br
+\fIsisu_vim\fR(7),
+.br
+\fIsisu_webrick\fR(1),
+.PP
+\fIsisu\-complete\fR(7),
+.br
+\fIsisu\-postgresql\fR(7),
+.br
+\fIsisu\-sqlite\fR(7).
+
+.SH HOMEPAGE
+More information about \fBSiSU\fR can be found at <\fIhttp://www.jus.uio.no/sisu/\fR>.
+
+.SH AUTHOR
+\fBSiSU\fR was written by Ralph Amissah <\fIralph@amissah.com\fR>.
diff --git a/debian/manpages/sisu-postgresql.7 b/debian/manpages/sisu-postgresql.7
new file mode 100644
index 00000000..7d757eba
--- /dev/null
+++ b/debian/manpages/sisu-postgresql.7
@@ -0,0 +1,34 @@
+.TH SISU\-POSTGRESQL 7 2010\-06\-19 2.5.1 SiSU
+
+.SH NAME
+\fBSiSU\fR \- Structured information, Serialized Units \- a document publishing system, complete dependency package
+
+.SH DESCRIPTION
+\fBSiSU\fR is a lightweight markup based document structuring, publishing and search framework for document collections.
+.PP
+The sisu\-postgresql package enables \fBSiSU\fR to populate a PostgreSQL database. This is done at an object/paragraph level, making granular searches of documents possible.
+.PP
+This relational database feature of \fBSiSU\fR is not required but provides interesting possibilities, including that of granular searches of documents for matching units of text, primarily paragraphs that can be displayed or identified by object citation number, from which an index of documents matched and each matched paragraph within them can be displayed.
+
+.SH SEE ALSO
+\fIsisu\fR(1),
+.br
+\fIsisu\fR(8).
+.br
+\fIsisu_termsheet\fR(1).
+.br
+\fIsisu_vim\fR(7),
+.br
+\fIsisu_webrick\fR(1),
+.PP
+\fIsisu\-complete\fR(7),
+.br
+\fIsisu\-pdf\fR(7),
+.br
+\fIsisu\-sqlite\fR(7).
+
+.SH HOMEPAGE
+More information about \fBSiSU\fR can be found at <\fIhttp://www.jus.uio.no/sisu/\fR>.
+
+.SH AUTHOR
+\fBSiSU\fR was written by Ralph Amissah <\fIralph@amissah.com\fR>.
diff --git a/debian/manpages/sisu-sqlite.7 b/debian/manpages/sisu-sqlite.7
new file mode 100644
index 00000000..5c25e058
--- /dev/null
+++ b/debian/manpages/sisu-sqlite.7
@@ -0,0 +1,34 @@
+.TH SISU\-SQLITE 7 2010\-06\-19 2.5.1 SiSU
+
+.SH NAME
+\fBSiSU\fR \- Structured information, Serialized Units \- a document publishing system, complete dependency package
+
+.SH DESCRIPTION
+\fBSiSU\fR is a lightweight markup based document structuring, publishing and search framework for document collections.
+.PP
+The sisu\-sqlite package enables \fBSiSU\fR to populate an SQLite database. This is done at an object/paragraph level, making granular searches of documents possible.
+.PP
+This relational database feature of \fBSiSU\fR is not required but provides interesting possibilities, including that of granular searches of documents for matching units of text, primarily paragraphs that can be displayed or identified by object citation number, from which an index of documents matched and each matched paragraph within them can be displayed.
+
+.SH SEE ALSO
+\fIsisu\fR(1),
+.br
+\fIsisu\fR(8).
+.br
+\fIsisu_termsheet\fR(1).
+.br
+\fIsisu_vim\fR(7),
+.br
+\fIsisu_webrick\fR(1),
+.PP
+\fIsisu\-complete\fR(7),
+.br
+\fIsisu\-pdf\fR(7),
+.br
+\fIsisu\-postgresql\fR(7).
+
+.SH HOMEPAGE
+More information about \fBSiSU\fR can be found at <\fIhttp://www.jus.uio.no/sisu/\fR>.
+
+.SH AUTHOR
+\fBSiSU\fR was written by Ralph Amissah <\fIralph@amissah.com\fR>.
diff --git a/debian/rules b/debian/rules
new file mode 100755
index 00000000..36ffc2d2
--- /dev/null
+++ b/debian/rules
@@ -0,0 +1,10 @@
+#!/usr/bin/make -f
+
+%:
+ dh ${@}
+
+override_dh_builddeb:
+ dh_builddeb -- -Zxz -z9
+
+override_dh_compress:
+ dh_compress -X.rb -X.ssi -X.ssm -X.sst -X.yml
diff --git a/debian/sisu-complete.manpages b/debian/sisu-complete.manpages
new file mode 100644
index 00000000..c4e82a6c
--- /dev/null
+++ b/debian/sisu-complete.manpages
@@ -0,0 +1 @@
+debian/manpages/sisu-complete.7
diff --git a/debian/sisu-pdf.install b/debian/sisu-pdf.install
new file mode 100644
index 00000000..7ee85249
--- /dev/null
+++ b/debian/sisu-pdf.install
@@ -0,0 +1 @@
+bin/sisu-pdf usr/bin
diff --git a/debian/sisu-pdf.manpages b/debian/sisu-pdf.manpages
new file mode 100644
index 00000000..bafebdc4
--- /dev/null
+++ b/debian/sisu-pdf.manpages
@@ -0,0 +1,2 @@
+man/man1/sisu-pdf.1
+debian/manpages/sisu-pdf.7
diff --git a/debian/sisu-postgresql.install b/debian/sisu-postgresql.install
new file mode 100644
index 00000000..02779e8d
--- /dev/null
+++ b/debian/sisu-postgresql.install
@@ -0,0 +1 @@
+bin/sisu-pg usr/bin
diff --git a/debian/sisu-postgresql.manpages b/debian/sisu-postgresql.manpages
new file mode 100644
index 00000000..8c2816b9
--- /dev/null
+++ b/debian/sisu-postgresql.manpages
@@ -0,0 +1,2 @@
+man/man1/sisu-pg.1
+debian/manpages/sisu-postgresql.7
diff --git a/debian/sisu-sqlite.install b/debian/sisu-sqlite.install
new file mode 100644
index 00000000..c5dae5e3
--- /dev/null
+++ b/debian/sisu-sqlite.install
@@ -0,0 +1 @@
+bin/sisu-sqlite usr/bin
diff --git a/debian/sisu-sqlite.manpages b/debian/sisu-sqlite.manpages
new file mode 100644
index 00000000..95221efe
--- /dev/null
+++ b/debian/sisu-sqlite.manpages
@@ -0,0 +1,2 @@
+man/man1/sisu-sqlite.1
+debian/manpages/sisu-sqlite.7
diff --git a/debian/sisu.NEWS.Debian b/debian/sisu.NEWS.Debian
new file mode 100644
index 00000000..bc693659
--- /dev/null
+++ b/debian/sisu.NEWS.Debian
@@ -0,0 +1,107 @@
+sisu (3.0.1-1) unstable; urgency=low
+
+ Version 3 is now the default (on running sisu). There are 3 possible output
+ structures set in sisurc.yml
+ "output_dir_structure_by: (language|filetype|filename)"
+ structure by "language" is the default set in /etc/sisu/v3/sisurc.yml
+ structure by "filename" is closest to the structure provided by v2, (however,
+ filenames have a language code addition)
+
+ Version 2 remains available (unchanged), invoked as 'sisu2' or 'sisu --v2'
+ (followed by usual instructions)
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 03 Oct 2011 21:25:19 -0400
+
+sisu (3.0.0-1) unstable; urgency=low
+
+ Version 3 development branch opened, version 1 retired (removed), processing
+ defaults version 2 stable. To run version 3, 'sisu3' or 'sisu --v3' (followed
+ by usual instructions), See version 3 upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Mon, 07 Feb 2011 10:53:18 -0500
+
+sisu (2.3.0-1) unstable; urgency=medium
+
+ SQL db structure addition (of Online Computer Library Center number) (v2c),
+ (if you use sisu search) it is necessary to: (a) recreate db and tables and
+ populate them, and; (b) to regenerate the sample search form (or modify any
+ search forms)
+
+ The postgresql db name prefix is now "SiSUv2c_"
+
+ This version includes many small fixes, see upstream changelog
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 27 Apr 2010 19:51:23 -0400
+
+sisu (2.2.0-1) unstable; urgency=medium
+
+ SQL db structure changes (v2b), (if you use sisu search) it is necessary to:
+ (a) recreate db and tables and populate them, and; (b) to regenerate the
+ sample search form (or modify any search forms)
+
+ The postgresql db name prefix is now "SiSUv2b_" [corrected]
+
+ This version includes fixes
+
+ [beats 2.1.0 to testing]
+
+ -- Ralph Amissah <ralph@amissah.com> Tue, 20 Apr 2010 19:33:31 -0400
+
+sisu (2.1.0-1) unstable; urgency=medium
+
+ Version 2.1 sql db structure changes, it is necessary to (a) recreate db and
+ tables and populate them, and (b) to regenerate the sample search form (or
+ modify any search forms)
+
+ The postgresql db name prefix is now "iSiSUv2a_" [corrected]
+
+ [There may be additional db structure changes on in the near future if these
+ are required after testing and review of this release]
+
+ This version also includes a number of fixes
+
+ -- Ralph Amissah <ralph@amissah.com> Fri, 16 Apr 2010 11:31:54 -0400
+
+sisu (2.0.0-1) unstable; urgency=low
+
+ Version 2, introducing some incompatibility as document headers have changed,
+ compare markup samples[*] provided in:
+ /usr/share/doc/sisu/v2/sisu_markup_samples/samples and
+ /usr/share/doc/sisu/v1/sisu_markup_samples/samples
+
+ If postgresql is made use of version 2 also makes its own databases and
+ leaves those of version 1 untouched
+
+ The version 1 engine remains available and can be invoked using:
+ sisu --v1 [operations]
+
+ [* version 2 of non-free package sisu-markup-samples provides additional
+ samples of markup at:
+ /usr/share/doc/sisu-markup-samples/v2/samples
+ /usr/share/doc/sisu-markup-samples/v1/samples
+ sisu-markup-sasmples package is non dfsg as book copyright holders place
+ some restrictions on what can be done with their work most commonly no
+ changing of content, and in some non commercial use]
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 06 Mar 2010 06:50:00 -0500
+
+sisu (0.62.0-1) unstable; urgency=medium
+
+ Output directory structure related to images and optional shared source
+ files has been changed, existing sites will need to be manually adjusted
+
+ * site images:
+ [outputpath]/_sisu/image_local is now [outputpath]/_sisu/image
+
+ * package images:
+ [outputpath]/_sisu/image is now [outputpath]/_sisu/image_sys
+
+ shared source if any now is placed in separate directories
+
+ * shared markup text:
+ [outputpath]/src
+
+ * shared (zipped) sisupods:
+ [outputpath]/pod
+
+ -- Ralph Amissah <ralph@amissah.com> Sat, 20 Oct 2007 15:04:46 +0100
diff --git a/debian/sisu.docs b/debian/sisu.docs
new file mode 100644
index 00000000..e845566c
--- /dev/null
+++ b/debian/sisu.docs
@@ -0,0 +1 @@
+README
diff --git a/debian/sisu.install b/debian/sisu.install
new file mode 100644
index 00000000..52cfe7f7
--- /dev/null
+++ b/debian/sisu.install
@@ -0,0 +1,27 @@
+debian/bin/sisu usr/bin
+debian/bin/sisu2 usr/bin
+debian/bin/sisu3 usr/bin
+debian/bin/sisu_termsheet usr/bin
+debian/bin/sisu_webrick usr/bin
+bin/sisu-concordance usr/bin
+bin/sisu-epub usr/bin
+bin/sisu-git usr/bin
+bin/sisu-harvest usr/bin
+bin/sisu-html usr/bin
+bin/sisu-odf usr/bin
+bin/sisu-po usr/bin
+bin/sisu-txt usr/bin
+lib/sisu usr/lib/ruby/1.9.1
+conf/sisu etc
+data/sisu usr/share
+data/doc/sisu usr/share/doc
+debian/data/doc/sisu usr/share/doc
+# depreciated remove once vim-addon-manager is in place
+data/sisu/v3/conf/editor-syntax-etc/vim/ftplugin/sisu.vim usr/share/vim/addons/ftplugin
+data/sisu/v3/conf/editor-syntax-etc/vim/syntax/sisu.vim usr/share/vim/addons/syntax
+# migrate to use vim-addon-manager
+data/sisu/v3/conf/editor-syntax-etc/vim/vim-sisu.yaml usr/share/vim/registry
+data/sisu/v3/conf/editor-syntax-etc/vim/ftplugin/sisu.vim usr/share/vim-scripts/ftplugin
+data/sisu/v3/conf/editor-syntax-etc/vim/syntax/sisu.vim usr/share/vim-scripts/syntax
+# installation of kate (and kde) is optional
+#data/sisu/v2/conf/editor-syntax-etc/kate/sisu.xml usr/share/apps/katepart/syntax
diff --git a/debian/sisu.lintian-overrides b/debian/sisu.lintian-overrides
new file mode 100644
index 00000000..cff33808
--- /dev/null
+++ b/debian/sisu.lintian-overrides
@@ -0,0 +1,12 @@
+# too long URLs
+sisu: manpage-has-errors-from-man
+sisu: script-not-executable usr/share/sisu/v2/conf/cgi-bin/sisu_search_pgsql.cgi
+sisu: script-not-executable usr/share/sisu/v2/conf/cgi-bin/sisu_search_sqlite.cgi
+sisu: script-not-executable usr/share/sisu/v2/conf/convert/kdissert_to_sisu
+sisu: script-not-executable usr/share/sisu/v2/conf/convert/modify.rb
+sisu: script-not-executable usr/share/sisu/v2/conf/convert/sisu_convert
+sisu: script-not-executable usr/share/sisu/v3/conf/cgi-bin/sisu_search_pgsql.cgi
+sisu: script-not-executable usr/share/sisu/v3/conf/cgi-bin/sisu_search_sqlite.cgi
+sisu: script-not-executable usr/share/sisu/v3/conf/convert/kdissert_to_sisu
+sisu: script-not-executable usr/share/sisu/v3/conf/convert/modify.rb
+sisu: script-not-executable usr/share/sisu/v3/conf/convert/sisu_convert
diff --git a/debian/sisu.manpages b/debian/sisu.manpages
new file mode 100644
index 00000000..97bd17f4
--- /dev/null
+++ b/debian/sisu.manpages
@@ -0,0 +1,14 @@
+man/man1/sisu.1
+man/man1/sisu2.1
+man/man1/sisu3.1
+man/man1/sisu-concordance.1
+man/man1/sisu-epub.1
+man/man1/sisu-git.1
+man/man1/sisu-harvest.1
+man/man1/sisu-html.1
+man/man1/sisu-odf.1
+man/man1/sisu-po.1
+man/man1/sisu-txt.1
+man/man1/sisu_webrick.1
+man/man1/sisu_termsheet.1
+man/man7/sisu_vim.7
diff --git a/debian/source/format b/debian/source/format
new file mode 100644
index 00000000..163aaf8d
--- /dev/null
+++ b/debian/source/format
@@ -0,0 +1 @@
+3.0 (quilt)
diff --git a/debian/source/options b/debian/source/options
new file mode 100644
index 00000000..c89bc49d
--- /dev/null
+++ b/debian/source/options
@@ -0,0 +1 @@
+compression�=�xz
diff --git a/debian/watch b/debian/watch
new file mode 100644
index 00000000..d064cf52
--- /dev/null
+++ b/debian/watch
@@ -0,0 +1,2 @@
+version=3
+http://www.jus.uio.no/sisu/archive/pool/main/s/sisu/sisu_(.*)\.tar\.xz