[Blends-commit] [SCM] blends-gsoc branch, master, updated. 12ad01d21cc2093a1b751d18f138d47a1c32a36c
Emmanouil Kiagias
e.kiagias at gmail.com
Mon Sep 16 19:17:12 UTC 2013
The following commit has been merged in the master branch:
commit 12ad01d21cc2093a1b751d18f138d47a1c32a36c
Author: Emmanouil Kiagias <e.kiagias at gmail.com>
Date: Mon Sep 16 21:06:53 2013 +0200
temporary store the doc/A_devel.sgml which contains the first documentation for blends-dev. Soon to be moved in official blends/doc/en/
diff --git a/doc/A_devel.sgml b/doc/A_devel.sgml
new file mode 100644
index 0000000..da63841
--- /dev/null
+++ b/doc/A_devel.sgml
@@ -0,0 +1,707 @@
+ <appendix id="DevelDescription">
+ <heading>Description of development tools</heading>
+ <sect id="blends-dev">
+ <heading>Package <package>blends-dev</package></heading>
+
+<p>
+If metapackages are builded using the tools inside the
+<package>blends-dev</package> package it can be ensured that the
+resulting metapackages will work nicely with the same version of
+<package>blends-common</package> package. The goal is to keep
+necessary changes for the source of the metapackages of a Debian Pure
+Blend as low as possible when the version of the
+<package>blends</package> source package changes. Thus it is
+strongly recommended to use the tools described below.
+</p>
+<p>
+The usage of the tools in the <package>blends-dev</package> package might
+introduce a versioned dependency in the
+<package><var><blend></var>-config</package> package from which
+all other metapackages of the <var>Blend</var> in question will
+depend. This <package><var><blend></var>-config</package> package
+instantiates the <var>Blend</var> in the common registry for all Blends in
+<file>/etc/blends</file>.
+</p>
+
+<p>
+The version <package>0.7.0</package> of <package>blends-dev</package> uses
+<url id="https://wiki.debian.org/UltimateDebianDatabase" name="UDD">
+to generate Blends' metapackages. Currently all Blends' info is stored into UDD.
+Information such as VCs, description, homepage etc for a Blend can be found into the
+<url id="http://udd.debian.org/schema/udd.html#public.table.blends-metadata" name="blends_metadata">
+UDD table. All the info about Blends' tasks and their package dependencies are also stored
+into the <url id="http://udd.debian.org/schema/udd.html#public.table.blends-tasks" name="blends_tasks"> and
+<url id="http://udd.debian.org/schema/udd.html#public.table.blends-dependencies-alternatives" name="blends_dependencies_alternatives">
+tables. Having the latter in combination with other UDD tables
+(such as a table with info about all Debian available packages)
+provides the ability to check whether a package exists for an architecture or not thus
+<package>blends-dev</package> can generate architecture dependent metapackages.
+</p>
+
+<p>
+The best idea to use the tools provided by the
+<package>blends-dev</package> is to put a <file>Makefile</file> into the
+build directory containing one single line
+
+<example>
+ include /usr/share/blends-dev/Makefile
+</example>
+
+(see <file>/usr/share/doc/blends-dev/examples/Makefile</file>).
+Users using <package>blends-dev 0.7.0</package> on existing Blends
+which have more than one releases might encouter some <file>Makefile</file>
+errors for more info see <ref id="statusdump"> and <ref id="changelogentry">.
+
+Using this <file>Makefile</file> all tools that were contained in
+<package>blends-dev</package> package versions before 0.4. These tools
+are moved to <file>/usr/share/blends-dev/</file> because there is no need
+to call them directly. Here is a list of the <file>make</file> targets.
+</p>
+
+<sect1 id="blends-tasks.desc">
+ <heading>Blend<tt>-tasks.desk</tt></heading>
+
+<p>
+This target generates a <package>task-description.template</package> file.
+The template can be converted to a proper description file that is used in
+<prgn>tasksel</prgn> to enable selecting the tasks belonging to the Blend.
+The initial template contains all the needed package dependencies
+for a Blend. But because some packages might not be available for a(or multiple)
+architectures the template uses the following syntax when specifying packages:
+<example> package1 [!arch1 arch2]</example>
+
+That says do not include the package1 in the
+taskdescription file when arch1 or arch2 is used.
+When a Blends' <package>orig.tar.gz</package> is generated,
+the initial template gets converted
+from the <package>blends-dev rules</package> file to a proper taskdescription file.
+The convertion is filtering out the packages which are not available for the
+host's (where the <package>orig.tar.gz</package> is generated) architecture.
+This make sure that the taskdescription file will not include package which are
+not available for the target architecture.
+Finally the file will be moved to the
+<var>blend</var><package>-tasks</package>. All information
+about Blends package dependencies is obtained from the UDD.
+</p>
+
+</sect1>
+<sect1 id="debian_control">
+ <heading><tt>debian/control</tt></heading>
+
+<p>
+The <file>debian/control</file> file of a Blend metapackage source
+archive is auto generated out of dependencies that are specified in so
+called <file>tasks</file> files. The rationale behind this is to
+enhance flexibility about changes inside the Debian package pool where
+new packages might appear and others might be renamed.
+The <file>tasks</file> just define which dependencies the Blend
+maintainer group wants to be fulfilled and the
+script <prgn>blend-gen-control</prgn> using UDD verifies whether these
+dependencies exist in a specified package pool. A
+package pool can be considered as the packages available for a
+combination of distribution, component and release values. By default when
+creating metapackages debian,main,testing values are used to "create" a package pool from UDD.
+Once a Blends' dependencies are verified the <file>debian/control</file> file is generated
+according to the available packages. This does not only work for the Debian package pool
+containing the distributions stable, testing and unstable. You can
+even build your metapackages against a different package pool of a
+Debian based distribution. This is for instance used to create the
+SkoleLinux metapackages.
+</p>
+
+<p>
+As mentioned in the previous section, using UDD in Blends' tools provides the ability to generate
+architecture dependent metapackages. Thus the generated
+<package>debian/control</package> specifies for every task source target as architecture value:
+<example>Architecture: any</example>
+
+Specifying <package>any</package> indicates that the source package isn't dependent
+on any particular architecture and should compile fine on any one. To fulfil this
+in case of missing packages <package>control</package> file uses the following syntax:
+
+<example>Depends: package1 [!arch1 !arch2]</example>
+
+If a package is not available for a specific arch, exclude it from it. So the above example says:
+depend on package1 but not when architecture arch1 or arch2 is used. More info about
+<package>debian/control</package> syntax can be found in
+<url id="http://www.debian.org/doc/debian-policy/" name="Debian Policy Manual" >
+</p>
+
+<p>
+The syntax of the <file>tasks</file> files which serve as the central
+database for the information in the <file>debian/control</file> file
+is defined by RFC822. Some of the tags were mentioned formerly in
+<ref id="packageslist"> to explain how the <file>tasks</file> files
+can be used to create the web sentinel pages. Now the tags that
+influence the creation of the <file>debian/control</file> file are given.
+</p>
+<p>
+ <taglist>
+ <tag>Depends</tag>
+ <item>Will be turned to "Recommends" in the
+ resulting <file>debian/control</file> file. The
+ rationale behind this is to enable installing the
+ metapackage even if a package belonging to this task is
+ missing for whatever reason. It also allows finally to
+ remove the metapackage. This makes even more
+ sense since <prgn>apt-get</prgn> considers "Recommends"
+ as default installation targets.
+ </item>
+ <tag>Recommends</tag>
+ <item>The packages that are listed as "Recommends" in the
+ tasks file should be installed on the machine where the
+ metapackage is installed and which are needed to work
+ on a specific task.
+ </item>
+ <tag>Suggests</tag>
+ <!-- [BA] Why would we suggest non-free? Doesn't policy allow a non-free
+ package to specify "Enhances" to avoid this problem?
+ [AT] I have to admit that "Enhances" is new to me. When
+ reading policy I think this field is out of control of
+ the metapackage developer because it has to be included
+ by the package maintainer. I'm not really convinced that
+ this is a good solution - but I would follow the suggestions
+ of others in this issue.
+ -->
+ <item><p>Use "Suggests" for packages of lesser importance that
+ might be possibly useful, or non-free packages.</p>
+ <p>
+ If a package is not available in the package pool of the
+ target distribution when creating
+ the <file>debian/control</file> file inside the meta
+ package source archive any "Depends" or "Recommends" are
+ turned into "Suggests" to enable a flawless installation
+ of the metapackage. Generally packages are concerned as missing if
+ they do not exist into Debian main component(default is testing release).
+ Packages that are specified with
+ "Suggests" will not be taken over to
+ the <prgn>tasksel</prgn> control file
+ (Blend<file>-tasks.desk</file>,
+ see <ref id="blends-tasks.desc">) but only to the list of
+ suggested packages of the according metapackage.
+ </item>
+ <tag>Ignore</tag>
+ <item>The "Ignore" key can be used as kind of "Soft-Suggests"
+ to put a package on the radar of the Blend. Packages that
+ are tagged with Ignore will not be taken over into the
+ list of dependencies inside
+ the <file>debian/control</file> file of the resulting
+ metapackage neither to the Blend<file>-tasks.desk</file>
+ control file for <prgn>tasksel</prgn> but will be taken
+ over onto the installation medium of a Blend in case there
+ is some space left. This key becomes especially
+ important for specifying not yet packaged software that
+ might be packaged in the future (prospective packages).
+ This is explained in detail in the paragraph about the
+ web sentinel (see <ref id="packageslist">).
+ </item>
+ <tag>Avoids</tag>
+ <item>The "Avoids" key specifies existing packages that will
+ be listed in the the <file>debian/control</file> file as
+ "Recommends" or "Suggests" but, should not go to a
+ installation medium (CD, DVD, etc.) that might be
+ produced by the Blend. A reason to avoid a package might
+ be that it belongs to the non-free section.
+ </item>
+ </taglist>
+</p>
+</sect1>
+
+<sect1 id="statusdump">
+ <heading><tt>statusdump</tt></heading>
+
+<p>
+This target generates a json file containing the latest package dependencies
+for the selected Blend. It parses the files from the <tt>tasks</tt> directory
+and generates a <var>blend</var><tt>_version.json</tt> into a <tt>dependency_data</tt>
+directory. As <tt>version</tt> it gets the latest version specified in the Blend's
+<tt>debian/changelog</tt> file. In case the <tt>dependency_data</tt> directory
+does not exist into a Blend's root directory it automatically creates it.
+</p>
+
+<p>
+A user can also generate a json dependencies file manually
+using the <tt>tasks_diff</tt> script. The script can be called
+from a Blend's root directory:
+
+<example>
+ /usr/share/blends-dev/task_diff --status-dump --tasks . --output blend_version.json
+</example>
+If the user does not specify the output argument the script by default
+will generate the json file under the <tt>tasks.json</tt> name in the
+current directory.
+</p>
+
+<p>
+Note: in case a user needs to generate a json file for a previous release
+(rather than the latest) to get the <tt>changelogentry</tt>
+(see <ref id="changelogentry">) target to work, must keep the following thing in mind:
+
+The user must provide to <tt>task_diff</tt> script the <em>root</em> directory of a previous Blend release
+(through the --task(-t) argument). He should also save the output into the <tt>dependency_data</tt>
+directory into the latest Blend release providing manually
+the name <var>blend</var><tt>_version.json</tt> (through the --output(-o) argument:
+
+<example>
+/usr/share/blends-dev/task_diff --status-dump -t blend/tags/previous/ -o latest_blend/dependency_data/blend_version.json
+</example>
+
+For example if the name of the Blend is <tt>myblend</tt> and the release is <tt>0.2.0</tt>
+then the json file must have the name <tt>myblend_0.2.0.json</tt>
+</p>
+
+</sect1>
+
+<sect1 id="changelogentry">
+ <heading>changelogentry</heading>
+
+<p>
+This target compares the latest and the previous Blend release and dumps the tasks'
+package differences. It reports the added/removed packages
+per task (or added/removed task files)
+between releases. This "report" is automatically
+added into the <tt>debian/changelog</tt>
+in the latest relase section under the file's manual changes.
+In case a previous difference report
+exists, it overrides it. In case a Blend does not have more than release
+(initial release) then this target is ignored.
+</p>
+
+<p>
+In order the comparison to be properly performed the
+<var>blend</var><tt>_version.json</tt> files for the two latest releases
+must exist under the <tt>dependency_data</tt> directory. In case any of the
+previous files is missing then the target will fail with an error
+(specifying the missing version_file). The json file for the latest
+release is automatically generated from the <tt>statusdump</tt> target
+so it this will not cause the problem.
+</p>
+
+<p>
+This changelog entry is a new feature so the problem of this target failing
+(because of a missing json file) will appear for existing Blends which have
+more than one releases and do not have a <var>blend</var><tt>_version.json</tt>
+for the previous release under their <tt>dependency_data</tt> directory.
+Usually Blend's releases are tagged into the VCs, so the previous problem
+can be solved by generating the dependency json file for the previous
+release (using a previous VCs tag). This can be done by calling manually
+the <tt>task_diff</tt> script (see <ref id="statusdump">)
+</p>
+
+</sect1>
+
+<sect1>
+ <heading>Apt <file>sources.list</file> files in <file>/etc/blends/</file></heading>
+<p>
+These files are used by <manref name="blend-gen-control" section="1"> to
+build valid <file>debian/control</file> files that contain only
+available packages in their dependencies. This enables building meta
+packages for <tt>stable</tt>, <tt>testing</tt>, <tt>unstable</tt> or
+even a completely different distribution that has valid
+<file>sources.list</file> entries. The file
+<file>/etc/blends/control.list</file> is used as default for <manref
+name="blend-gen-control" section="1"> and usually is a symbolic link
+(see <manref name="ln" section="1">) to
+<file>sources.list.</file><var>distribution</var>. It might be
+changed using the <tt>-s </tt><var>dist</var> option of <manref
+name="blend-gen-control" section="1">.
+</p>
+<p>
+<strong>TODO:</strong> <em>Either parse the available
+<file>/etc/apt/sources.list</file> or use a sane <prgn>debconf</prgn>
+question to use the "nearest" mirror.</em>
+</p>
+</sect1>
+
+<sect1>
+ <heading>Templates in <file>/usr/share/blends/templates</file></heading>
+<p>
+The directory <file>/usr/share/blends/templates</file> contains templates
+that can be used to build a <var><blend></var><package>-config</package>,
+which uses the tools that are contained in the
+<package>blends-common</package> package, and are useful to manage
+<var><blend></var> user groups (see <ref id="userroles">).
+</p>
+</sect1>
+</sect>
+
+<sect id="blends-common">
+ <heading>Package <package>blends-common</package></heading>
+
+<p>
+This package creates a common registry for all Blends in
+<file>/etc/blends</file>. Each Blend should put the files that are used
+into a subdirectory named like the Blend of <file>/etc/blends</file>. The
+<package>blends-common</package> package installs a common configuration
+file <file>/etc/blends/blends.conf</file>, which can be used to influence the
+behaviour of the tools described below.
+</p>
+
+<sect1>
+ <heading><!-- document type does not allow element "MANREF" here--><tt>blend-role(8)</tt></heading>
+<p>
+<taglist>
+ <tag>NAME</tag>
+ <item>
+ <prgn>blend-role</prgn> - add/remove roles in registered Debian Pure Blend
+
+ </item>
+ <tag>SYNOPSIS</tag>
+ <item>
+ <prgn>blend-role</prgn> <var>add|del</var> <var>Blend</var> [<var>Role</var>]
+ </item>
+ <tag>DESCRIPTION</tag>
+ <item>Add/remove (register/unregister) <var>Role</var> for the
+ specified <var>Blend</var>. If <var>Role</var> is not specified, it's
+ assumed to be named like <var>Blend</var>.
+ </item>
+
+
+ <tag>OPTIONS</tag>
+ <item>
+ <taglist>
+ <tag><var>Blend</var></tag>
+ <item>A registered Blend in /etc/blends, for example
+ one of <tt>med</tt>, <tt>junior</tt>,
+ <tt>edu</tt> or <tt>science</tt>
+ </item>
+ </taglist>
+ </item>
+ <tag>AUTHOR</tag>
+ <item>Andreas Tille <email>tille at debian.org</email>,
+ Cosimo Alfarano <email>kalfa at debian.org</email>.</item>
+</taglist>
+</p>
+</sect1>
+
+<sect1 id="blend-update-menus">
+ <heading><!-- document type does not allow element "MANREF"
+ here--><tt>blend-update-menus(8)</tt></heading>
+<p>
+<taglist>
+ <tag>NAME</tag>
+ <item>
+ <prgn>blend-update-menus</prgn> - add menu of metapackage to all Blend users
+ </item>
+ <tag>SYNOPSIS</tag>
+ <item>
+ <prgn>blend-update-menus</prgn> [<var>--blend Blend</var> | <var>--user
+ user</var>]
+ </item>
+ <tag>DESCRIPTION</tag>
+ <item>
+ <p>
+ blend-update-menus behaves differently depending on who run the
+ command:
+ </p>
+
+ <p>
+ If it is called by a user, it adds, and keeps updated, menu
+ entries for the user who runs it.
+ </p>
+
+ <p>
+ If it is called by root, it adds and keeps updated user's menu
+ entries (see menu package for users' menus) for all users who
+ belong to the group of the specified Blend, or only for a specified
+ user, depending on which parameter is passed to the script.
+ </p>
+ </item>
+
+ <tag>OPTIONS</tag>
+ <item>
+ <taglist>
+ <tag><var>Blend</var></tag>
+ <item>one of the installed Blends, listed in /etc/blends/, for example
+ (if installed: <tt>med</tt>, <tt>junior</tt>,
+ <tt>edu</tt> or <tt>science</tt>.
+ </item>
+ <tag><var>user</var></tag>
+ <item>system user</item>
+ </taglist>
+ </item>
+ <tag>AUTHOR</tag>
+ <item>Andreas Tille <email>tille at debian.org</email>,
+ Cosimo Alfarano <email>kalfa at debian.org</email>.</item>
+</taglist>
+</p>
+</sect1>
+
+<sect1>
+ <heading><!-- document type does not allow element "MANREF" here--><tt>blend-user(8)</tt></heading>
+<p>
+<taglist>
+ <tag>NAME</tag>
+ <item>
+ <prgn>blend-user</prgn> - add/remove user to Role of a registered Blend
+
+ </item>
+ <tag>SYNOPSIS</tag>
+ <item>
+ <prgn>blend-user</prgn> <var>add|del</var> <var>Blend</var> <var>user</var> [<var>Role</var>]
+ </item>
+ <tag>DESCRIPTION</tag>
+ <item>Add/remove user to a <var>Role</var> of the specified <var>Blend</var>.
+
+ If <var>Role</var> is not specified, it's assumed to be named like
+ <var>Blend</var>
+ </item>
+
+
+ <tag>OPTIONS</tag>
+ <item>
+ <taglist>
+ <tag><var>Blend</var></tag>
+ <item>A registered Blend in /etc/blends, for example
+ one of <tt>med</tt>, <tt>junior</tt>,
+ <tt>edu</tt> or <tt>science</tt>.
+ </item>
+ <tag><var>user</var></tag>
+ <item>user to add</item>
+ <tag><var>Role</var></tag>
+ <item>the role in the <var>Blend</var> that <var>user</var> will
+ assume</item>
+ </taglist>
+ </item>
+ <tag>AUTHOR</tag>
+ <item>Andreas Tille <email>tille at debian.org</email>,
+ Cosimo Alfarano <email>kalfa at debian.org</email>.</item>
+</taglist>
+</p>
+</sect1>
+
+<sect1>
+ <heading><tt>blends.conf(5)</tt></heading>
+<p>
+<taglist>
+ <tag>NAME</tag>
+ <item>
+ <file>blends.conf</file> - configuration for Debian Pure Blends registry
+ </item>
+ <tag>DESCRIPTION</tag>
+ <item>This file is sourced from shell scripts inside the Debian
+ Pure Blends package <package>blends-common</package> and thus
+ it has to follow shell syntax. The variables that are set
+ inside this configuration file can be overriden by special
+ Blend configration files
+ <file>/etc/blends/<var><>Blend></var>/<var><>Blend></var>.conf</file>
+ for each single Blend.
+ <tag>SYNTAX</tag>
+ <item>The following variables can be set:
+ <taglist>
+ <tag><tt>DBBACKEND</tt></tag>
+ <item>Set the backend for the user role management system.
+ Currently the only implemented role management system is
+ <tt>unixgroups</tt> but others might be implemented
+ later. Unsetting this variable leads to use no roles at all.
+ </item>
+ <tag><tt>UPDATEUSERMENU</tt></tag>
+ <item>If this is set to <tt>yes</tt>, the user menus of meta
+ packages can be created automatically at install time of
+ the package if the postinst script of the package allows
+ this. It is suggested to use this option in the specific
+ configuration files of a special Debian Pure Blend that
+ override the settings of the general configuration file.
+ </item>
+ <tag><tt>SHAREDIR</tt></tag>
+ <item>Set the base directory for the user role management
+ system. While this is more or less a feature for
+ debugging this might be also used otherwise.
+ </item>
+ <tag><tt>DRYRUN</tt></tag>
+ <item>This variable can be set for debugging. Normally it
+ should be left unset (<em>NOT</em> set to <tt>false</tt>
+ or anything else!). If set to <tt>true</tt> a dry run of
+ the tools is performed or <tt>echo DRYRUN:</tt> would
+ print debugging information.
+ </item>
+ <tag><tt>DEBUG</tt></tag>
+ <item>If set to <tt>1</tt> debugging mode is switched on.
+ </taglist>
+ </item>
+ <tag>SEE ALSO</tag>
+ <item>
+ <file>blend-role (8)</file>, <file>blend-update-menus (8)</file>,
+ <file>blend-user (8)</file>
+ </item>
+ <tag>AUTHOR</tag>
+ <item>Andreas Tille <email>tille at debian.org</email>,
+ Cosimo Alfarano <email>kalfa at debian.org</email>.</item>
+</taglist>
+</p>
+</sect1>
+
+</sect>
+
+
+<sect id="svn">
+ <heading>Working with the source repository (<file>svn</file> in process of moving to <file>git</file>)</heading>
+<p>
+ Sometimes it might be interesting for developers to check out the
+ latest code of the Blend tools or a special Blend code for the meta
+ packages. In <ref id="communication"> the directory layout of the
+ <file>svn</file>-directory was described. How to derive the
+ Debian packages from this layout?
+<taglist>
+ <tag>Checkout</tag>
+ <item>
+ For the Blend tools and this documentation
+<example>
+ git clone git+ssh://<var>username</var>@git.debian.org/git/blends/blends.git
+</example>
+ or for the Debian Pure Blend <var>BLEND-name</var>
+<example>
+ svn checkout svn+ssh://<var>username</var>@svn.debian.org/svn/blends/projects/<var>BLEND-name</var>/trunk
+</example>
+ Note: This will be moved to Git (at least) soon after Wheezy release.
+ </item>
+ <tag>Build source package</tag>
+ <item>
+ Change into the created directory and type
+<example>
+ make -f debian/rules get-orig-source
+</example>
+ This creates a <file>tar.gz</file> source archive of the packages
+ you want to build. For your personal comfort you can create a
+ file <file>Makefile</file> in your package source directory containing
+<example>
+ #!/usr/bin/make -f
+ include /usr/share/blends-dev/Makefile
+</example>
+ Which enables you to simply say
+<example>
+ make dist
+</example>
+ to create the source tarball.
+ </item>
+ <tag>Build Debian packages</tag>
+ <item>
+ Unpack the created source tarball and proceed like you build
+ Debian packages normally.
+ </item>
+</taglist>
+</p>
+<p>
+The current Debian Med packages provide a working example how to use
+the tools described below.
+</p>
+</sect>
+
+ <sect id="webpagecreation">
+ <heading>How to create tasks and bugs pages of web sentinel</heading>
+
+<p>
+In <ref id="sentinel"> the creation of so called tasks
+pages <ref id="packageslist"> and bugs pages <ref id="bugs"> was
+described. These pages are automatically build by a cron job on Alioth
+from the current state of the tasks files in the SVN repository.
+If you have commited changes to the tasks pages and want to see the
+effect immediately the steps to do are as follows:
+</p>
+<p>
+<enumlist>
+ <item>Login to <tt>alioth.debian.org</tt></item>
+ <item><tt>cd /var/lib/gforge/chroot/home/groups/blends/webtools/</tt></item>
+ <item><tt>./tasks.py <blend-name></tt></item>
+</enumlist>
+</p>
+<p>
+To know what a valid <tt><blend-name></tt> might be have a look
+into
+<tt>/var/lib/gforge/chroot/home/groups/blends/webtools/webconf</tt>.
+Each Blend has an according config file there. Leave out
+the <tt>.conf</tt> extension and you have a
+valid <tt><blend-name></tt>.
+</p>
+<p>
+In case you are planing some more experimental changes there is
+another host which was kindly sponsored by Frédéric Hébert for Debian
+Med called <tt>blends.debian.net</tt> which is running a copy of
+UDD and also hosts the latest development snapshot of the Blends web
+tools. Just ask Andreas Tille <email>tille at debian.org</email> in case
+you like a login on this host.
+</p>
+<p>
+The code which builds web and tasks pages is available in Git at
+<tt>git://git.debian.org/git/blends/website.git</tt>. It is
+using the <url id="http://genshi.edgewall.org/" name="Genshi
+templating system"> which enables influencing the layout of the pages
+by editing the templates in the
+<file>templates</file> directory.
+You can also influence some parameters of the web pages in the
+configuration files in the <file>webconf</file> directory.
+Last but not least you can provide translations for the web pages in
+the <file>po</file> directory.
+</p>
+<p>
+Once something on the web pages was changed you can activate the
+changes as follows:
+</p>
+<p>
+<enumlist>
+ <item>Login to <tt>alioth.debian.org</tt> or <tt>blends.debian.net</tt></item>
+ <item><tt>cd /var/lib/gforge/chroot/home/groups/blends/webtools/</tt></item>
+ <item><tt>git pull</tt></item>
+</enumlist>
+</p>
+<p>
+Please note that the <tt>css</tt> and <tt>js</tt> files which are
+influencing the layout of the automatically created pages are in
+the same area as the static web pages (see below <ref id="staticwebpages">).
+</p>
+</sect>
+
+ <sect id="staticwebpages">
+ <heading>Editing static web pages of Blends on Alioth</heading>
+<p>
+A very simple entry page is created for each Blend which is linked
+from the
+<url id="http://blends.alioth.debian.org/" name="list of all Blends">.
+Most probably the maintainers of a Blend want to enhance this page a
+bit. It is actually intended that this simple template will be
+enhanced as it is done for instance for the
+<url id="http://debian-med.alioth.debian.org" name="Debian Med
+project"> which has a quite complex PHP driven web with a lot of other
+features than just linking to the tasks and bugs pages. Maintainers
+of a Blend should care for this index page which currently is just
+featuring links to the automatically updated pages as well as an image
+which shows the activity of the
+<url id="http://people.debian.org/~tille/talks/200808_lightning/liststats.pdf"
+name="relevant mailing list">. Maintaining these static pages is
+not a "service" which is done for you. The maintainers of a Blend
+should care for this!
+</p>
+<p>
+The static pages are maintained in Git at
+<tt>git://git.debian.org/git/blends/website.git</tt> in the
+<file>websites</file> directory.
+Once you have changed the content of the pages you can activate
+the changes by doing:
+</p>
+<p>
+<enumlist>
+ <item>Login to <tt>alioth.debian.org</tt> or <tt>blends.debian.net</tt></item>
+ <item><tt>cd /var/lib/gforge/chroot/home/groups/blends/webtools/</tt></item>
+ <item><tt>git pull</tt></item>
+</enumlist>
+</p>
+</sect>
+ </appendix>
+
+<!-- Keep this comment at the end of the file
+Local variables:
+mode: sgml
+sgml-omittag:nil
+sgml-shorttag:t
+sgml-namecase-general:t
+sgml-general-insert-case:lower
+sgml-minimize-attributes:nil
+sgml-always-quote-attributes:t
+sgml-indent-step:2
+sgml-indent-data:t
+sgml-parent-document:("../debian-blends.en.sgml" "book" "chapt")
+sgml-exposed-tags:nil
+sgml-local-catalogs:nil
+sgml-local-ecat-files:nil
+End:
+-->
--
Git repository for blends-gsoc code
More information about the Blends-commit
mailing list