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) <kana...@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-February/msg00115.html";
/>
+ </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) <kana...@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) <kana...@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
+
_______________________________________________
revisor-devel mailing list
revisor-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/revisor-devel
