| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Use arch considerations in yumcfg like the repos module.
This involved promoting fedora_arch to be a global option.
|
| |
|
|
|
|
|
|
| |
Along the way, add basic support for handling boolean
values in python and shell scripts in modules.
[dsd: trivial tweaks: renamed to --cache-only, use variable presence in
environment for boolean testing, add documentation]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As recently discussed on the devel list, we switch to a new naming
scheme for builds, encompassing more details than before.
See http://wiki.laptop.org/go/Release_Process#Version_numbering
for more info.
The name is now built from:
1. Fourth digit of the four-digit year corresponding to the Major Release
2. The release number within the current year
3. Three-digit zero-padded build number
4. An alphabetic 'deployment identifier', max 2 characters
5. A numeric code identifying the target laptop model.
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of listing all the modules in [global].modules,
load all modules specified in the .ini file using [module] notation.
This makes the config file format more friendly to making a build
from various config files specified together, and avoids the annoying
cases when you add a new [configuration section] but forget to add
the module to the module list (not realising your mistake until after
the build has completed).
|
| |
|
|
|
|
|
| |
Allow multiple config files to be specified on the command line.
They will be parsed in the order specified.
This replaces the additional-defaults functionality provided before.
|
| |
|
|
|
|
|
| |
Files placed at $intermediatesdir/shared can now be accessed at
/build_shared from within the build environment
Based on work by Jerry Vonau
|
| |
|
|
|
| |
We can now produce post-release releases containing small fixes to
the build system, criteria documented in README.devel.
|
| | |
|
| |
|
|
|
| |
As suggested by Martin Langhoff, we should be using SafeConfigParser
which is more predictable than the now-discouraged ConfigParser.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Path references in the config file can now refer to %(oob_config_dir)s
which resolves to the directory where the config file resides.
Additionally, scripts will find $oob_config_dir defined in the environment.
For example this will find a custom script in the same dir as the config
file:
[custom_scripts]
custom_script_1=%(oob_config_dir)s/myscript.sh
In a custom script, this will apply a patch in the same directory as the
config file:
patch $INSTALL_DIR/etc/foo < $oob_config_dir/foo.patch
[dsd: minor tweak, add documentation]
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Conflicts:
doc/README
|
| | |
| |
| |
| |
| |
| |
| | |
In Nicaragua I realised that we'd like to retain the old naming scheme of
having e.g. nic802-2
Allow a template to be specified in the build config that allows for this.
|
| | |
| |
| |
| | |
Pointed out by Simon Schampijer
|
| |/
|
|
| |
Didn't realise this was available in Fedora.
|
| |
|
|
| |
Pointed out by Bernie.
|
| |
|
|
|
| |
This means that the additional defaults file can be used to add modules
to the list, without having to copy the whole list.
|
| |
|
|
|
|
|
| |
Tested olpc-os-builder on Fedora 11, and documented the steps required
to produce a build in a Quick Start section of the README.
Reformatted the previous text.
|
| | |
|
|
|
Basic functionality is working, needs more testing and a comparison
to the OLPC OS 10.1.0 release.
|
