6:59 p.m.
doc/Revisor_Documentation/en-US/Appendix.xml | 169 +++++++
doc/Revisor_Documentation/en-US/Revisor_Documentation.xml | 334 +++++++++++++-
revisor/base.py | 18
unity/scripts/mock_respins.sh | 32 +
4 files changed, 550 insertions(+), 3 deletions(-)
New commits:
commit 4221c77781bd9cf5410b47e49da9529329f15eeb
Author: Jeroen van Meeuwen (Fedora Unity) <kanarip(a)fedoraunity.org>
Date: Wed Feb 11 01:58:32 2009 +0100
Update documentation
diff --git a/doc/Revisor_Documentation/en-US/Appendix.xml
b/doc/Revisor_Documentation/en-US/Appendix.xml
index 55d3e01..38ee4a0 100644
--- a/doc/Revisor_Documentation/en-US/Appendix.xml
+++ b/doc/Revisor_Documentation/en-US/Appendix.xml
@@ -9,6 +9,9 @@
<title>Terminology</title>
<formalpara
id="Revisor_Documentation-Appendix-Terminology-Remix">
<title>Remix</title>
+ <indexterm>
+ <primary>Remix</primary>
+ </indexterm>
<para>
A Fedora Remix is a product based on Fedora, with Fedora packages and
optionally, other packages as well, such as those from third-party repositories.
</para>
@@ -16,6 +19,10 @@
<formalpara
id="Revisor_Documentation-Appendix-Terminology-Re-Spin">
<title>Re-Spin</title>
+ <indexterm>
+ <primary>Re-Spin</primary>
+ <secondary>Fedora Unity Re-Spin</secondary>
+ </indexterm>
<para>
A Fedora Re-Spin is a product that is composed for the single purpose of
including updated software packages into the product. It uses the same compose procedure
as the media that the Fedora Project composes and releases, but includes updates.
</para>
@@ -26,6 +33,9 @@
<formalpara
id="Revisor_Documentation-Appendix-Terminology-Spin">
<title>Spin</title>
+ <indexterm>
+ <primary>Spin</primary>
+ </indexterm>
<para>
A Fedora Spin is a custom set of software packages, often for a specific
audience. Spins include a KDE Spin, which contains KDE software packages rather then the
Desktop spin, which is based around GNOME. Similarly, there are XFCE, LXDE, Sugar,
Education, Games and Developer Spins.
</para>
@@ -36,6 +46,9 @@
<formalpara
id="Revisor_Documentation-Appendix-Terminology-Package_Sack">
<title>Package Sack</title>
+ <indexterm>
+ <primary>Package Sack</primary>
+ </indexterm>
<para>
para
</para>
@@ -80,6 +93,19 @@
</thead>
<tbody>
<row>
+ <entry namest="column1"
nameend="column25"><literal>answer_yes</literal></entry>
+ <entry namest="column67"
nameend="column89"><literal>-y</literal>,
<literal>--yes</literal></entry>
+ </row>
+ <row>
+ <entry namest="column25">0,
1</entry>
+ <entry>0</entry>
+ <entry>global, model</entry>
+ </row>
+ <row>
+ <entry namest="column25"
nameend="column89">Answer <emphasis>yes</emphasis> to all
questions.</entry>
+ </row>
+
+ <row>
<entry namest="column1"
nameend="column25"><literal>clean_up</literal></entry>
<entry namest="column67"
nameend="column89"><literal>--clean-up</literal></entry>
</row>
@@ -93,6 +119,32 @@
</row>
<row>
+ <entry namest="column1"
nameend="column25"><literal>copy_dir</literal></entry>
+ <entry namest="column67"
nameend="column89"><literal>--copy-dir</literal></entry>
+ </row>
+ <row>
+ <entry
namest="column25"><code>[dir]</code></entry>
+ <entry>False</entry>
+ <entry>global, model</entry>
+ </row>
+ <row>
+ <entry namest="column25"
nameend="column89">A directory tree to copy onto the media created. In the
case of installation media, the contents of the directory specified are copied onto
<code>cdrom:/files/</code>. In the case of live media, the contents of the
directory specified are copied onto the root filesystem of the live system.</entry>
+ </row>
+
+ <row>
+ <entry namest="column1"
nameend="column25"><literal>copy_local</literal></entry>
+ <entry namest="column67"
nameend="column89"><literal>--copy-local</literal></entry>
+ </row>
+ <row>
+ <entry
namest="column25"> </entry>
+ <entry>False</entry>
+ <entry>global, model</entry>
+ </row>
+ <row>
+ <entry namest="column25"
nameend="column89">Tell Revisor to copy files, even when they are local. This
applies to relative corner-cases where the repositories or the
<code>destination_directory</code> is mounted over NFS, and some actions
cannot be performed.</entry>
+ </row>
+
+ <row>
<entry namest="column1"
nameend="column25"><literal>debuglevel</literal></entry>
<entry namest="column67"
nameend="column89"><literal>-d</literal>,
<literal>--debug</literal></entry>
</row>
@@ -106,6 +158,32 @@
</row>
<row>
+ <entry namest="column1"
nameend="column25"><literal>destination_directory</literal></entry>
+ <entry namest="column67"
nameend="column89"><literal>--destination-directory</literal></entry>
+ </row>
+ <row>
+ <entry
namest="column25"><code>/srv/revisor/</code></entry>
+
<entry><code>[path]</code></entry>
+ <entry>global, model</entry>
+ </row>
+ <row>
+ <entry namest="column25"
nameend="column89">The destination directory for the product. Revisor creates
a sub-directory with the name of the model used, and places the product in that
directory.</entry>
+ </row>
+
+ <row>
+ <entry namest="column1"
nameend="column25"><literal>getsource</literal></entry>
+ <entry namest="column67"
nameend="column89"><literal>--source</literal></entry>
+ </row>
+ <row>
+ <entry
namest="column25"> </entry>
+ <entry>False</entry>
+ <entry>global, model</entry>
+ </row>
+ <row>
+ <entry namest="column25"
nameend="column89">Whether to obtain the source along with the binary RPMs
used. This is False by default, and therefor the source is not included by default. Note
that if you are distributing your product to third parties, you need to be able to provide
the sources along with the binary product.</entry>
+ </row>
+
+ <row>
<entry namest="column1"
nameend="column25"><literal>include_bootiso</literal></entry>
<entry namest="column67"
nameend="column89"><literal> </literal></entry>
</row>
@@ -119,6 +197,19 @@
</row>
<row>
+ <entry namest="column1"
nameend="column25"><literal>kickstart_default</literal></entry>
+ <entry namest="column67"
nameend="column89"><literal>--kickstart-default</literal></entry>
+ </row>
+ <row>
+ <entry namest="column25">0,
1</entry>
+ <entry>0</entry>
+ <entry>global, model</entry>
+ </row>
+ <row>
+ <entry namest="column25"
nameend="column89">Whether to set the isolinux.cfg entry that makes the
installer use the kickstart included on the media, as a default.</entry>
+ </row>
+
+ <row>
<entry namest="column1"
nameend="column25"><literal>kickstart_exact</literal></entry>
<entry namest="column67"
nameend="column89"><literal>--kickstart-exact</literal></entry>
</row>
@@ -145,6 +236,45 @@
</row>
<row>
+ <entry namest="column1"
nameend="column25"><literal>kickstart_file</literal></entry>
+ <entry namest="column67"
nameend="column89"><literal>--kickstart</literal></entry>
+ </row>
+ <row>
+ <entry
namest="column25"><code>[file]</code></entry>
+ <entry>0</entry>
+ <entry>global, model</entry>
+ </row>
+ <row>
+ <entry namest="column25"
nameend="column89">What kickstart file to use. When in CLI mode, this is a
mandatory setting.</entry>
+ </row>
+
+ <row>
+ <entry namest="column1"
nameend="column25"><literal>kickstart_include</literal></entry>
+ <entry namest="column67"
nameend="column89"><literal>--kickstart-include</literal></entry>
+ </row>
+ <row>
+ <entry namest="column25">0,
1</entry>
+ <entry>0</entry>
+ <entry>global, model</entry>
+ </row>
+ <row>
+ <entry namest="column25"
nameend="column89">Whether to include the kickstart on the media so that the
installer may find it as <filename>cdrom:/ks.cfg</filename>.</entry>
+ </row>
+
+ <row>
+ <entry namest="column1"
nameend="column25"><literal>kickstart_save</literal></entry>
+ <entry namest="column67"
nameend="column89"><literal>--kickstart-save</literal></entry>
+ </row>
+ <row>
+ <entry namest="column25">0,
1</entry>
+ <entry>0</entry>
+ <entry>global, model</entry>
+ </row>
+ <row>
+ <entry namest="column25"
nameend="column89">Where to save the resulting kickstart. In GUI mode, when
changes to the package set can be applied, saves those changes out into a new kickstart
file.</entry>
+ </row>
+
+ <row>
<entry namest="column1"
nameend="column25"><literal>media_installation_bluray_duallayer</literal></entry>
<entry namest="column67"
nameend="column89"><literal>--install-bluray-dl</literal></entry>
</row>
@@ -262,6 +392,19 @@
</row>
<row>
+ <entry namest="column1"
nameend="column25"><literal>model</literal></entry>
+ <entry namest="column67"
nameend="column89"><literal>--model</literal></entry>
+ </row>
+ <row>
+ <entry
namest="column25"> </entry>
+
<entry><code>[model]</code></entry>
+ <entry>global</entry>
+ </row>
+ <row>
+ <entry namest="column25"
nameend="column89">The model to use.</entry>
+ </row>
+
+ <row>
<entry namest="column1"
nameend="column25"><literal>report_sizes</literal></entry>
<entry namest="column67"
nameend="column89"><literal>--report_sizes</literal></entry>
</row>
@@ -274,6 +417,32 @@
<entry namest="column25"
nameend="column89">Report the sizes of RPM packages used. Lists the biggest
packages in the transaction</entry>
</row>
+ <row>
+ <entry namest="column1"
nameend="column25"><literal>mode_respin</literal></entry>
+ <entry namest="column67"
nameend="column89"><literal>--respin</literal></entry>
+ </row>
+ <row>
+ <entry
namest="column25"> </entry>
+ <entry>False</entry>
+ <entry>global, model</entry>
+ </row>
+ <row>
+ <entry namest="column25"
nameend="column89">Whether Revisor should operate in
<emphasis>respin</emphasis> mode. See also <xref
linkend="Revisor_Documentation-Compose_Process_Details-Respin_Mode"
/></entry>
+ </row>
+
+ <row>
+ <entry namest="column1"
nameend="column25"><literal>working_directory</literal></entry>
+ <entry namest="column67"
nameend="column89"><literal>-d</literal>,
<literal>--debug</literal></entry>
+ </row>
+ <row>
+ <entry namest="column25">0 -
9</entry>
+ <entry>0</entry>
+ <entry>global, model</entry>
+ </row>
+ <row>
+ <entry namest="column25"
nameend="column89">The level of debugging. 0 is the lowest debug level,
whereas 9 is the highest. Revisor turns up the volume quickly. The logfile on debug level
9 may very easily become 20-30MB.</entry>
+ </row>
+
</tbody>
</tgroup>
</table>
diff --git a/doc/Revisor_Documentation/en-US/Revisor_Documentation.xml
b/doc/Revisor_Documentation/en-US/Revisor_Documentation.xml
index bddccdd..1e09676 100644
--- a/doc/Revisor_Documentation/en-US/Revisor_Documentation.xml
+++ b/doc/Revisor_Documentation/en-US/Revisor_Documentation.xml
@@ -577,8 +577,177 @@
<para>
para
</para>
+
+ <section
id="Revisor_Documentation-Compose_Process_Details-Overview">
+ <title>Overview</title>
+ <para>
+ Of course, the compose process for installation media is a little
different then the compose process for live media.
+ </para>
+ <para>
+ When composing, Revisor starts out doing the following:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Revisor reads the options from the CLI and takes
<code>--config</code>, if specified.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Revisor reads the configuration file specified with
<code>--config</code>, or it's default,
<filename>/etc/revisor/revisor.conf</filename>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Revisor reads the global <code>[revisor]</code>
section for all settings available and sets those configured in the global section.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ If a model is specified in the configuration file's
global section <code>[revisor]</code>, Revisor will set that model to be used
and loads it.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ If a model has been specified on the command-line, with
option <code>--model</code>, Revisor loads that model.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Revisor checks every settings against a function that is
specifically written to check such setting. For example, the label of an ISO cannot be
longer then 32 characters.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Especially in CLI mode, these settings build up the task list
for Revisor. If there's nothing to do, Revisor will throw an error explaining
what's missing. If there's things to do that cannot be done in one run, Revisor
will throw an error explaining that.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ In GUI mode however, if the settings are compatible, the GUI
will start.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section
id="Revisor_Documentation-Compose_Process_Details-Respin_Mode">
+ <title>Respin Mode</title>
+ <para>
+ Revisor has a respin mode that in some aspects differs from the regular
routines. It is intended to reflect behaviour of tools in use by the Fedora Project
Release Engineering team as closely as possible.
+ </para>
+ <para>
+ Re-Spin mode only affects installation media products.
+ </para>
+ <para>
+ In Re-Spin mode, the way the RPM payload is determined from kickstart
differs from Revisor's normal procedures. See <xref
linkend="Revisor_Documentation-Using_Kickstart" /> for more details on using
a kickstart package manifest.
+ </para>
+ <para>
+ A kickstart file's so-called package manifest usually looks like:
+ </para>
+ <para>
+ <screen>%packages
+@group1
+@group2 --nodefaults
+@group3 --optional
+package1
+package2
+-package3
+%end</screen>
+ </para>
+ <para>
+ Which tells us the following:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Include all mandatory and default packages from group1
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Include all mandatory packages from group2
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Include all mandatory, default and optional packages from
group3
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Include package1, and package2
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Exclude package3
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ Depending on how you use this instructions or information, there is a
slight difference in the package set that ends up on the media you compose.
+ </para>
+
+ <section
id="Revisor_Documentation-Compose_Process_Details-Respin_Mode-Selecting_Groups">
+ <title>Selecting Groups</title>
+ <para>
+ Selecting groups has the following logic: When you load a repository
you may also load the groups file (often referred to as 'comps' or
'comps.xml'). This comps file is an XML file with categories, groups (per
category), and per group:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ a list of mandatory packages. If you select or include
the group, these packages come with it.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ a list of default packages. If you select or include the
group, these packages will come with it as a default. If you only want the mandatory,
minimum set of packages for this group, in a kickstart package manifest append
<code>--nodefaults</code> to the group line or in the Revisor GUI,
right-click on the group and choose <emphasis>Deselect all
packages</emphasis>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ a list of optional packages. If you select a group you
have not yet selected these packages. To select the optional packages of a group, in a
kickstart package manifest append <code>--optional</code> to the group line or
in the Revisor GUI, right-click on the group and choose <emphasis>Select all
optional packages</emphasis>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ a list of conditionals. If you select this group, these
conditionals are thrown into the package sack and transaction information and include or
exclude other packages. Suppose you select the '@nl-support' or “Dutch Support”
group from the Languages or Localization category, you would end up with support for the
Dutch language in all applications that have that kind of support.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section
id="Revisor_Documentation-Compose_Process_Details-Respin_Mode-Select_Matching_Packages">
+ <title>Select Matching Packages</title>
+ <para>
+ This is the logic Revisor applies when running in Re-Spin mode (on
the CLI, specify <code>--respin</code>). It imitates the behavior pungi has,
and thus enables you to copy that behavior. Note that <code>--respin</code>
has other implications as well.
+ </para>
+ <para>
+ First of all, it iterates the groups in the kickstart package
manifest. For each group, it appends the names of the mandatory packages to a list, and
depending on the additional parameters specified with that group
(<code>--nodefaults</code> or <code>--optional</code>), appends
the names of the other packages in that group as well.
+ </para>
+ <para>
+ Then it iterates over the package names in the package manifest.
These package names are appended to the same list of package names too. This includes
package 'names' with some sort of wildcard (?, or *).
+ </para>
+ <para>
+ Then it iterates over all the excluded packages, appending each of
those to the YUM configuration exclude list.
+ </para>
+ <para>
+ Now that Revisor has a very simple, flat list of package names, it
uses YUM's internal matching logic 5 to get what packages in the repositories matched
exactly (by name), matched (by wildcard) and did not match at all. Revisor then selects
the exact matches and matches, adding them to the transaction.
+ </para>
+ </section>
+ </section>
+
<section
id="Revisor_Documentation-Compose_Process_Details-Dependency_Resolving">
<title>Dependency Resolving</title>
+ <indexterm>
+ <primary>Dependency Resolving</primary>
+ </indexterm>
<para>
Dependency resolving is the area where some of the efficiency Revisor can
gain for you comes from. While of course there is specific reasons to do things one way,
or the other, most people I speak to about Revisor, it is not very clear why, or what
Revisor does in this area. First of all, there's two ways of resolving dependencies:
</para>
@@ -587,6 +756,10 @@
<listitem>
<formalpara>
<title>Inclusive Dependency Resolving</title>
+ <indexterm>
+ <primary>Dependency Resolving</primary>
+ <secondary>Inclusive</secondary>
+ </indexterm>
<para>
Iterate all packages in the transaction and list their
requirements, then for each of those requirements, find all packages that provide a
matching capability, add those packages to the transaction, and don't forget to add
the requirements those packages have themselves, back into the pile of (unmet)
requirements.
</para>
@@ -595,6 +768,10 @@
<listitem>
<formalpara>
<title>Exclusive Dependency Resolving</title>
+ <indexterm>
+ <primary>Dependency Resolving</primary>
+ <secondary>Inclusive</secondary>
+ </indexterm>
<para>
Iterate all the packages and for each of the requirements
found, find the best package that meets the requirement. This is also YUMs default
behavior. Anaconda uses YUM during the installation, and this is the behaviour of YUM used
during the installation.
</para>
@@ -905,6 +1082,20 @@ while more_to_do:
</para>
</formalpara>
+ <formalpara
id="Revisor_Documentation-Frequently_Asked_Questions-Relationship_Between_Revisor_and_Pungi">
+ <title>What is the relationship between Revisor and
Pungi?</title>
+ <para>
+ Where pungi builds a bunch of RPMs into ISO images and installation trees
through one single procedure, perfect for Release Engineering on something like the Fedora
Project, Revisor does it different entirely.
+ </para>
+ </formalpara>
+
+ <formalpara
id="Revisor_Documentation-Frequently_Asked_Questions-Relationship_Between_Revisor_and_Livecd-tools">
+ <title>What is the relationship between Revisor and
livecd-tools?</title>
+ <para>
+ Revisor depends on livecd-tools for the composing of live media. Creating
the filesystem to install the packages to, turning that image file into a SquashFS file,
and applying the settings inside the chroot.
+ </para>
+ </formalpara>
+
<formalpara
id="Revisor_Documentation-Frequently_Asked_Questions-Why_Rebuild_Installer_Images">
<title>Why Rebuild Installer Images?</title>
<para>
@@ -923,8 +1114,87 @@ while more_to_do:
<section id="Revisor_Documentation-Testing-Simple_Test_Cases">
<title>Simple Test Cases</title>
<para>
- para
+ This section has a few simple test cases ensuring configuration shipped
with Revisor works as anticipated.
</para>
+
+ <section
id="Revisor_Documentation-Testing-Simple_Test_Cases-Configuration_Files">
+ <title>Configuration Files</title>
+ <para>
+ The main Revisor configuration file is
<filename>/etc/revisor/revisor.conf</filename>. The file lists a series of
models, each having their own YUM configuration file in
<filename>/etc/revisor/conf.d/</filename>.
+ </para>
+ <formalpara>
+ <title>Testing</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ For each model in
<filename>/etc/revisor/revisor.conf</filename>, the
<code>main</code> setting for that model should point to a valid file.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Each YUM configuration file should work. To verify,
run the following command for each configuration file:
+ </para>
+ <para>
+ <screen>$ yum -c
<replaceable>$file</replaceable> list kernel</screen>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </formalpara>
+ <formalpara>
+ <title>Known Errors</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Revisor has baseurls in YUM repositories set to
<ulink url="http://localrepo" />. This URL will not be retrievable for
many people, but allows the developers to quickly change mirrors.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Repositories that are unavailable at the moment of
testing will throw errors Revisor can't do anything about.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ If the directories
<filename>revisor-yumcache/</filename> and
<filename>revisor/</filename> in <filename>/var/tmp/</filename>,
the default working directory, are not writeable for the user then YUM will throw
permission denied errors.
+ </para>
+ <para>
+ Remove
<filename>/var/tmp/revisor/</filename> and
<filename>/var/tmp/revisor-yumcache/</filename> or run the command with root
permissions.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </formalpara>
+ </section>
+
+ <section
id="Revisor_Documentation-Testing-Simple_Test_Cases-Compose_Results">
+ <title>Requirements for Compose Results</title>
+ <para>
+ Although heavily dependent on Anaconda for this part, these are still
requirements
+ </para>
+
+ <formalpara>
+ <title>ld-linux.so.2</title>
+ <para>
+ In the <filename>initrd.img</filename> of the
composed product, if 32-bit, <filename>/lib/ld-linux.so.2</filename> (or any
other version) should link to <filename>/lib/ld-2.9.so</filename> (or any
other version). If <filename>/lib/ld-linux.so.2</filename> links to itself,
the media will fail to install.
+ </para>
+ </formalpara>
+ <formalpara>
+ <title>How to test</title>
+ <para>
+ In a terminal, type the following command:
+ </para>
+ </formalpara>
+ <para>
+ <screen>$ <userinput>lsinitrd /path/to/initrd | grep
ld-linux</userinput></screen>
+ </para>
+ <para>
+ See also: <ulink
url="https://www.redhat.com/archives/anaconda-devel-list/2009-Februa...
/>
+ </para>
+
+ </section>
</section>
<section id="Revisor_Documentation-Testing-Complex_Test_Cases">
@@ -1081,6 +1351,68 @@ while more_to_do:
</para>
</section>
+ <section
id="Revisor_Documentation-Development-Adding_A_New_Spin">
+ <title>Adding a new spin or remix</title>
+ <para>
+ <orderedlist>
+ <listitem>
+ <para>
+ Add the appropriate models in the appropriate configuration
file for Revisor.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Add the appropriate configuration file to the appropriate
automake Makefile
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Run autoreconf && ./configure
&& make rpm to verify the rpm building
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Create the model's YUM configuration files with the
following repositories:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ fedora, enabled, pointing to Everything
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ fedora-source, disabled, pointing to Everything
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ fedora-updates, enabled, pointing to the updates
repository
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ fedora-updates-source, disabled, pointing to the
updates repository
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ anaconda-updates, enabled, pointing to the
anaconda updates repository
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ anaconda-updates-source, disabled, pointing to
the ananconda updates repository
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </listitem>
+ </orderedlist>
+ </para>
+ </section>
+
<section
id="Revisor_Documentation-Development-Versioning_Schema">
<title>Versioning Schema</title>
<para>
commit 0323188416a673417015104a5c50c35144b0aa19
Author: Jeroen van Meeuwen (Fedora Unity) <kanarip(a)fedoraunity.org>
Date: Wed Feb 11 01:57:35 2009 +0100
Make copying the installation tree over to it's new location a little more
efficient
diff --git a/revisor/base.py b/revisor/base.py
index af18de5..75ae3c6 100644
--- a/revisor/base.py
+++ b/revisor/base.py
@@ -1999,9 +1999,23 @@ class RevisorBase:
if self.cfg.media_installation_tree:
tree_dst =
os.path.join(self.cfg.destination_directory,"os",self.cfg.architecture)
tree_src = mypungi.topdir
- self.log.debug(_("Copying %s to %s") % (tree_src,tree_dst),
level=1)
+
+ # Find the number of files in tree_src for a progress bar
+ num_files = 0
+ for root, dirs, files in os.walk(tree_src):
+ num_files += len(files)
+
try:
- shutil.copytree(tree_src,tree_dst)
+ if self.cfg.copy_local:
+ self.log.debug(_("Copying %s to %s (%d files)") %
(tree_src,tree_dst,num_files), level=1)
+ shutil.copytree(tree_src,tree_dst)
+ else:
+ try:
+ self.log.debug(_("Moving %s to %s (%d files)") %
(tree_src,tree_dst,num_files), level=1)
+ shutil.move(tree_src,tree_dst)
+ except Exception, e:
+ self.log.error(_("Moving of the installation tree failed
(trying copy):\n\n%s") % '\n'.join(e), recoverable=True)
+ shutil.copytree(tree_src,tree_dst)
except Exception, e:
self.log.error(_("Copying of the installation tree
failed:\n\n%s") % '\n'.join(e), recoverable=True)
commit 7f7958fa59d94aaef70ea2a0a1d7dc9f32f2715a
Author: Jeroen van Meeuwen (Fedora Unity) <kanarip(a)fedoraunity.org>
Date: Wed Feb 11 01:57:07 2009 +0100
Add mock_respins.sh
diff --git a/unity/scripts/mock_respins.sh b/unity/scripts/mock_respins.sh
new file mode 100755
index 0000000..286ea26
--- /dev/null
+++ b/unity/scripts/mock_respins.sh
@@ -0,0 +1,32 @@
+#!/bin/bash
+
+mock -v -r fedora-10-i386 init && \
+mock -v -r fedora-10-i386 install comps-extras createrepo rhpl pykickstart \
+ livecd-tools anaconda-runtime squashfs-tools \
+ busybox-anaconda notify-python usermode \
+ pam python automake intltool gettext \
+ desktop-file-utils glib2-devel gcc \
+ cobbler koan deltarpm pygtk pygtk2-libglade \
+ gnome-python2-gconf system-config-kickstart jigdo \
+ livecd-tools python-virtinst git sudo spin-kickstarts
mock && \
+echo -en "git clone git://git.fedorahosted.org/revisor\n" | mock -r
fedora-10-i386 shell
+echo -en "cd /revisor; ./switchhere --yes\n" | mock -r fedora-10-i386 shell
+echo -en "cd /revisor; autoreconf && ./configure\n" | mock -r
fedora-10-i386 shell
+echo -en "rm -rf /var/lib/rpm/__db.00*\n" | mock -r fedora-10-i386 shell
+echo -en "cd /revisor; ./revisor.py --cli --config
/etc/revisor-unity/f10-install-respin.conf --model f10-i386-respin --debug 9\n" |
mock -r fedora-10-i386 shell
+
+mock -v -r fedora-10-x86_64 init && \
+mock -v -r fedora-10-x86_64 install comps-extras createrepo rhpl pykickstart \
+ livecd-tools anaconda-runtime squashfs-tools \
+ busybox-anaconda notify-python usermode \
+ pam python automake intltool gettext \
+ desktop-file-utils glib2-devel gcc \
+ cobbler koan deltarpm pygtk pygtk2-libglade \
+ gnome-python2-gconf system-config-kickstart jigdo \
+ livecd-tools python-virtinst git sudo spin-kickstarts
mock && \
+echo -en "git clone git://git.fedorahosted.org/revisor\n" | mock -r
fedora-10-x86_64 shell && \
+echo -en "cd /revisor; ./switchhere --yes\n" | mock -r fedora-10-x86_64 shell
&& \
+echo -en "cd /revisor; autoreconf && ./configure\n" | mock -r
fedora-10-x86_64 shell && \
+echo -en "rm -rf /var/lib/rpm/__db.00*\n" | mock -r fedora-10-x86_64 shell
&& \
+echo -en "cd /revisor; ./revisor.py --cli --config
/etc/revisor-unity/f10-install-respin.conf --model f10-x86_64-respin --debug 9\n" |
mock -r fedora-10-x86_64 shell
+