1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
|
olpc-os-builder is an application to generate OS images for XO
laptops. It is the successor to pilgrim and fedora-xo which were used
to generate prior OLPC OS releases.
Quick Start:
1. install Fedora 14,
2. install the build package:
yum install olpc-os-builder
3. produce a build:
olpc-os-builder /usr/share/doc/olpc-os-builder-*/examples/f14-xo1.5.ini
4. view or use the build result files:
ls -l /var/tmp/olpc-os-builder
Description:
The build is made based from a build configuration, which selects a
series of modules which were installed by olpc-os-builder. These
modules (and the configuration you provide) control the outcome of the
build process.
olpc-os-builder lets you build your own OLPC OS builds, with your own
customizations. In fact, one of the design goals is to make it easier
for OLPC deployments to make their own customizations. In this case,
the general usage model is to take one of the example configurations
which corresponds to the OLPC OS that you want to ship, and then make
a handful of modifications according to your local requirements.
These example configurations exactly match the build configurations
that OLPC used to make the published OS release.
When using olpc-os-builder in this fashion, you should take care to
match your runtime environment with the one that OLPC used when the
base OS image was originally released. For example, if OLPC OS
release 10.2.0 was built with olpc-os-builder-1.0.3 on Fedora 11, and
you want to modify this particular release but you are using
olpc-os-builder-1.2.0 on Fedora 12 then the output images may differ
significantly from the official OLPC OS release 10.2.0, which is
probably not what you want.
The example build configurations encode the version of olpc-os-builder
which was used by OLPC at the time that each build was made. With
this information, olpc-os-builder will warn you at the start of a
build when you attempt to build such an image on a configuration that
differs from the environment where the corresponding official OLPC OS
release was made.
Usage:
olpc-os-builder <path to build config>
Configuration:
Various build configurations can be found in the examples directory
included with the distribution, including configurations used to build
OLPC OS releases.
Build configuration files have a series of sections, each section
title is enclosed in square brackets. Inside each section, there are
options. For example, "mysection" below has one option, named
"option1" with value "myvalue":
[mysection]
option1=myvalue
Options can reside on multiple lines, provided that all lines beyond
the first one are indented, e.g.:
[mysection]
option1=this is
an option
that spans 4 lines
but lines 2 through 4 must be indented
option2=foo
Interpolation (basic assignment and use of variables) can be used, according
to Python's SafeConfigParser documentation.
Default variables automatically provided:
oob_config_dir
The directory where the currently selected config file resides
In general, each section that can exist in the configuration file
corresponds to a specific module. The section name is the same as the
module name. The options that can exist in these sections are
documented in the individual module documentation files.
There is one exception: the [global] section does not belong to any
module. So we'll document it here, according to each possible
setting:
fedora_release
The numeric release number of the Fedora operating system to base
the OLPC OS build on. For example, 11 for Fedora 11.
olpc_version_major
The major version component of the OLPC version tag to include in
the OS image. For example, in the OLPC OS 10.1.0 release, this
would be 10.
olpc_version_minor
The minor version component of the OLPC version tag to include in
the OS image. For example, in the OLPC OS 10.1.0 release, this
would be 1.
olpc_version_release
The release version component of the OLPC version tag to include
in the OS image. For example, in the OLPC OS 10.1.0 release, this
would be 0.
image_name
The naming scheme to use for the output files. The value of this field
must include "%%d", this will be replaced with the build number.
For example, a value of "per%%d-6" would result the output being called
"per703-6" for build number 703. The default value is "os%%d".
The reason that 2 percentage signs are needed is because RawConfigParser
is in use; a % therefore triggers the INI interpolation feature, unless
presented in the escaped form %%.
customization_info
Please set this to a string that indicates your identity, to make
clear that the resultant build is a modified version of OLPC's
official release. For example, you could use something like
"customized for Paraguay" when producing an OS build for OLPC's
Paraguayan deployment.
target_platform
A textual description of the target platform for the build, for
example XO-1.5.
langs
A set of languages to support in the resultant OS image.
modules
A comma-separated selection of modules to include in the build.
modules_<ANYTHING>
Additional modules to include (allowing you to append to the list of
modules in an additional configuration file)
include
Additional config files to include (non-recursive). Except for
global.modules, your main config will override values set in the
included configs. You can use all values defined in the DEFAULT
sections of the included configs for interpolation.
In general, options need to be set with care. Aim to stick with the
values shown in the examples where possible. For example, if you were
to exclude the "base" module from the build then you will get strange
results. Also, you cannot arbitrarily change fedora_release without
adapting all of the module code to work with the ever-changing
components of each official Fedora release.
Design goals:
- revolve around Fedora's image-creator infrastructure, meaning that
we use a lot of Fedora's official build infrastructure
- allow XO-1 and XO-1.5 builds from the codebase
- limit all configuration to a single INI-style text file
- through the configuration file, allow common deployment
modifications to be made without too much technical know-how
- copy elements of dracut's modular design to achieve the above
- eliminate the need for image-builder, which had the undesirable
effect of replicating some of the build infrastructure in 2 places
- avoid any 'difficult' system requirements so that this can be
packaged into official Fedora and hence easily installed and used
by deployments
Development:
See README.devel
Contact:
devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
|
