MeeGo wiki - User contributions [en]

Main Page

2011-07-14T08:26:00Z

Kevinwang: /* MeeGo Project Functions */

== MeeGo Project Functions ==
* [[Community Office]]
* [[Localization team|Localization]]
* [http://meego.com/about/governance/program-office Program Office]
* [[Core_OS_Program | Core OS Program]]
* [[Handset_Program | Handset UX Program]]
* [[In-vehicle | In Vehicle Infotainment - IVI]]
* [[Product Management]]
* [[Quality]]
* [[Distribution]]
* [[Release_Engineering|Release Engineering]]
* [http://meego.com/about/governance/ui-design User Interface Design]
* [[SDK]]
* [[Architecture]]
* [[Meego IT]]

= User =

* [[MeeGo Netbook FAQ]]
* [http://meego.com/devices/netbook/installing-meego-your-netbook Install MeeGo on your netbook]
* [[Devices|Supported devices]]
* [[Install MeeGo from Hard Disk]]

= Developer =
== Developer Guide ==

* [[SDK/Docs/1.1|Developer Guide for MeeGo 1.1]]
* [[SDK/Docs/1.0|Developer Guide for MeeGo 1.0]]
* [[Build_Infrastructure | Build Infrastructure]]
* [[MeeGo Porting Guide]]
* [[QML tutorials]] - Some tutorials to help get started with QML, the Qt Modelling Language.
* [http://mxr.meego.com/ MeeGo cross reference] - Index of MeeGo source code
* [[Brief_git_guide|Brief git guide]] - An overview of git as well as an example about how to use gitorious to do a merge request.

Other documents:
{| border="1"
! Document
! Variety (Version)
! Architectures
|-
|Instructions for [[ARM|ARM based devices (N900, BeagleBoard, PandaBoard, Snowball)]]
|All
|ARM
|-
|Instructions for [[MeeGo_1.0_Netbook_VirtualBox|VirtualBox]]
|Netbook (1.0)
|Intel
|-
|Instructions for [[MeeGo SDK on Windows with VirtualBox]]
|All
|All
|-
|Tips for [[Developing With The Aava]]
|Handset/Aava
|Intel
|}

== Release Process ==
The MeeGo Release Process includes:
* [[Release_Engineering/Process|Release process and work flow]]
* [[Release_Engineering/Release_Timeline|MeeGo releases every 6 months]]
* [[Release_Engineering/Process|Nightly builds for developers and weekly releases will be available]]

== MeeGo Components ==
* [[MeeGo_UX_Components|MeeGo Components]] - Supported common QML components

= Community =

== Contributing to MeeGo ==
* Read our [[Community guidelines]]: [[Wiki contribution guidelines|Wiki]], [[Mailing list guidelines|mailing list]], [[Forum/Guidelines|forum]], [[Gitorious_guidelines|Gitorious guidelines]] and [[Community guidelines|more]].
* [[Community communication|Participate in our forums, mailing lists, and more]].
* [http://meego.com/about/contribution-guidelines Contribute to MeeGo].
* [[Build_Infrastructure/Community_Builder|Building applications]] for MeeGo

See also [[Who's who]].

== Meetings ==

[[MeeGo-Meeting IRC Schedule]]

The following groups have regular meetings, see their respective pages for details.

* [[Technical Steering Group meetings]]
* [[Community Office/Meetings|Community Office meetings]]
* [[Localization team]]

Regional Activities.
* [[Local MeeGo Networks]]

== Bi-Annual MeeGo Conference ==

'''Upcoming Conferences'''
* [[MeeGo Conference Spring 2011|Spring 2011: May 23 - 25 at the Hyatt Regency, San Francisco]]
* [[MeeGo Conference Fall 2011|Fall 2011: November Date TBD in Europe]]

'''Past Conference Wrap-Up Information'''
* [[MeeGo_Conference_2010|Fall 2010: November 15 - 17 in Dublin]]

== Structure and Governance ==

MeeGo is an open source project led by the MeeGo Technical Steering Group (TSG). The governance model is based on meritocracy and the best practices and values of the Open Source culture. The MeeGo project lives under the auspices of the Linux Foundation.

* [http://meego.com/about/governance MeeGo Project Structure and Governance Overview]
* Bi-weekly [[Technical Steering Group meetings]]
* [[Working Group Process]]

== Resources ==
* [[MeeGo FAQ]]
* [[Glossary|Glossary and Acronyms]]
* [[Community guidelines]]
* [[Special:PopularPages|Popular Wiki Pages]]
* [[Special:MostLinkedPages|Most Linked-to Pages]]

[[Category:Top level]]

Image Creation For Beginners

2011-07-08T14:26:32Z

Kevinwang: /* STEP 4 - Create MeeGo LiveUSB Image */

MeeGo Image Creator is the tool we use to create MeeGo images. Here are the simple steps on how to create a MeeGo image.
For more in-depth information, go to the main Image Creator developer's guide: [[Image Creation]]
__TOC__
== Creating a MeeGo Image ==

===STEP 1 - Install Meego Image Creator (MIC)===

To install it:
* on OpenSuse
sudo zypper addrepo http://repo.meego.com/MeeGo/tools/repos/opensuse/11.4/ meego-tools
sudo zypper refresh
sudo zypper install mic2
* on Fedora
add repo like this:
# cat <<REPO > /etc/yum.repos.d/meego-tools.repo
[meego-tools]
name=MeeGo Tools for Fedora
baseurl=http://repo.meego.com/MeeGo/tools/repos/fedora/\$releasever
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-meego
REPO
add gpg key:
# gpg2 --keyserver subkeys.pgp.net --recv 0BC7BEC479FC1F8A
# gpg2 --export --armor 0BC7BEC479FC1F8A > /etc/pki/rpm-gpg/RPM-GPG-KEY-meego
Install mic2:
# yum install mic2
* on MeeGo
sudo zypper addrepo http://repo.meego.com/MeeGo/tools/repos/meego/1.1/ meego-tools
sudo zypper refresh
sudo zypper install mic2
* on Ubuntu or Debian:
For Ubuntu 10.10, add the below line to /etc/apt/sources.list
deb http://repo.meego.com/MeeGo/tools/repos/ubuntu/10.10/ /
For Debian 5.0, add the below line to /etc/apt/sources.list
deb http://repo.meego.com/MeeGo/tools/repos/debian/5.0/ /
Install mic2:
$sudo apt-get update
$sudo apt-get install mic2
* Download MIC source from Gitorious:
http://meego.gitorious.org/meego-developer-tools/image-creator

More on installation dependencies and options on downloading MIC, go to the 'Installation' section here: [[Image_Creation#Installation_Requirements]]

===STEP 2 - Get MeeGo .ks File===

KickStart (.ks) configuration files are passed to MIC to create images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

The official MeeGo .ks files are here:

Formal release: http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build: http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the MeeGo images you create. Modify these .ks files as you wish to create tailored images.

For details about how to modify the ks file, please refer: http://wiki.meego.com/Image_Configurations_-_KickStart_Files

===STEP 3 - Create MeeGo Livecd Image===

MIC has to be run with root privileges using 'sudo'.

Here is the command to create a MeeGo livecd image you can burn onto a CD.

<pre>
sudo mic-image-creator --config=default.ks --format=livecd --cache=mycache
</pre>

A file named meego-1.2-default-XX.iso is created. This ISO image is a hybrid image and can be either written to a disk device or burned onto a cd.

===STEP 4 - Create MeeGo LiveUSB Image===

To create a MeeGo liveusb image that you can transfer to a USB stick.

<pre>
sudo mic-image-creator --config=default.ks --format=liveusb --cache=mycache
</pre>

A file named meego-1.2-default-XX.usbimg will be created. To burn it onto a USB stick, run the following command:

<pre>
sudo mic-image-writer meego-1.2-default-XX.usbimg
</pre>

This image has a FAT file system and can be mounted easily on Windows and other OSes.

== Configure Proxy and Other Variables ==

~/.mic2.conf is a configuration file that can make your life easier by specifying proxy settings, cache directories, and other variables that you normally would have to re-type in your command-line.

Copy and paste this into a file called: ~/.mic2.conf

Replace with your own relevant values.

<pre>
[main]
cachedir=/home/user1/mycache
tmpdir=/home/user1/mystorage/tmp
outdir=/home/user1/mystorage
proxy=http://my.proxy.com:911/
no_proxy=localhost,127.0.0.0/8,.mysite.com,172.16.0.0/16
</pre>

''cachedir'' = directory where the cached repo(s) will reside. With this variable set, you do not need to pass the --cache flag in the command-line.

''tmpdir'' = temporary directory used by mic2 when creating images. With this variable set, you do not need to pass the --tmpdir flag in the command-line.

''outdir'' = where your images will reside once they are created. With this variable set, you do not need to pass the --outdir flag in the command-line.

''proxy'' = specify your proxy if you're behind a behind a firewall.

''no_proxy'' = specify what domains should not sure the proxy setting.

'''Note:''' When specifying proxy and no_proxy, you do not need to use the --proxy flag in your .ks files when referring to repos.

'''---FOR ADDITIONAL INFORMATION ON MIC, PLEASE VISIT THE MIC DEVELOPER'S GUIDE HERE: [[Image_Creation]]---'''

Another language version of this page

* [[适合新手的镜像制作-_-简体中文]]

Distribution

2011-07-07T23:24:41Z

Kevinwang: /* Overview */

This page describes basic information you needed if you want to contribute to MeeGo. Target audience is community member who wish to involve in MeeGo development.

== Package Management and Development ==
=== Overview ===
[[File:Distribution-process-overview-with-obs.png|thumb|250px|right|The development process when using OBS]]
[[File:Distribution-process-without-obs.png|thumb|250px|right|The development process w/o using OBS]]
Like other Linux distros, MeeGo is a package-based system, and it is using [http://www.rpm.org/max-rpm/index.html RPM] package end. The RPM packages are managed in [http://wiki.meego.com/Zypper Zypper] repos. The MeeGo development is using [http://wiki.opensuse.org/Portal:Build_Service Open Build Service (OBS)] to manage and build packages. If you are a serious and frequent MeeGo contributor, you need an OBS account to commit your changes back to MeeGo. Casual contributors can work without using OBS, and submit your changes back into MeeGo through the [http://lists.meego.com/mailman/listinfo mailing list] or work with the package maintainers to submit changes.

The overall processes of development with and without an OBS account are shown in the right figures. Detail description of the processes can be found below.

=== Development with MeeGo OBS account ===
* [[Build_Infrastructure/Packagers_Developers#How_to_get_started|Request a new OBS account]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_1|OBS WebUI: Login and first steps]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_2|OBS WebUI: Link packages and adding a repository]]
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_commandline_client|How to use the command line client for daily operations]]
* [[Build_Infrastructure/Packagers_Developers/Using_OBS_chroot_for_development|Using OBS chroot for development]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]
* [[Build_Infrastructure/Packagers_Developers#Troubleshooting|Troubleshooting]]

=== Development without MeeGo OBS account ===
* [[Local_Build_Without_OBS_Needed|Build and develop packages without OBS ]]
* [[Recompile_kernel | Example: Recompile kernel]]
* [[How to development with multiple packages with dependencies]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]

=== Packaging ===
* [[Packaging/Guidelines|Packaging Guidelines]]

=== Submission to MeeGo ===
* [[Release_Engineering/New_Package_Checklist|Checklist for new package submissions]]
* [[Release_Engineering/Submission_Checklist|Developer's checklist for code submissions]]
* [[Build_Infrastructure/Packagers_Developers#IRC_.2F_mailinglists_.2F_contact|irc / mailing lists / contact]]

== Software Repo ==
* [[Create and update repos]]
* [[Distribution/Package_Management|Package Management]]

== Developer Tools ==
=== Image Creation ===
* [[Image_Creation_For_Beginners|MIC2 for Beginners]]
* [[Image_Creation|MIC2]]
* [[Image Configurations - KickStart Files]]

=== OBS command line ===
* Part 1 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_1|initial setup]]
* Part 2 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|checkout & branch]]
* Part 3 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_4|more commands: localcheckbuild]]

=== Spec tool ===
* [[Spectacle|Spectacle]]

== Distribution Infrastructure ==
* [[Build_Infrastructure|Build Infrastructure - OBS]]
* [[Release_Infrastructure/BOSS|Release Infrastructure - BOSS]]

== Links ==
* [[Release_Engineering|Release Engineering]]
* [[Quality/Compliance|Compliance]]
* [[Quality|Quality]]

Distribution

2011-07-07T23:23:59Z

Kevinwang: /* Overview */

This page describes basic information you needed if you want to contribute to MeeGo. Target audience is community member who wish to involve in MeeGo development.

== Package Management and Development ==
=== Overview ===
[[File:Distribution-process-overview-with-obs.png|thumb|250px|right|The development process when using OBS]]
[[File:Distribution-process-without-obs.png|thumb|250px|right|The development process w/o using OBS]]
Like other Linux distros, MeeGo is a package-based system, and it is using [http://www.rpm.org/max-rpm/index.html RPM] package end. The RPM packages are managed in [http://wiki.meego.com/Zypper Zypper] repos. The MeeGo development is using [http://wiki.opensuse.org/Portal:Build_Service Open Build Service (OBS)] to manage and build packages. If you are a serious and frequent MeeGo contributor, you need an OBS account to commit your changes back to MeeGo. Casual contributors can work without using OBS, and submit your changes back into MeeGo through the [http://lists.meego.com/mailman/listinfo mailing list] or submit the changes to the package maintainer.

The overall processes of development with and without an OBS account are shown in the right figures. Detail description of the processes can be found below.

=== Development with MeeGo OBS account ===
* [[Build_Infrastructure/Packagers_Developers#How_to_get_started|Request a new OBS account]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_1|OBS WebUI: Login and first steps]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_2|OBS WebUI: Link packages and adding a repository]]
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_commandline_client|How to use the command line client for daily operations]]
* [[Build_Infrastructure/Packagers_Developers/Using_OBS_chroot_for_development|Using OBS chroot for development]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]
* [[Build_Infrastructure/Packagers_Developers#Troubleshooting|Troubleshooting]]

=== Development without MeeGo OBS account ===
* [[Local_Build_Without_OBS_Needed|Build and develop packages without OBS ]]
* [[Recompile_kernel | Example: Recompile kernel]]
* [[How to development with multiple packages with dependencies]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]

=== Packaging ===
* [[Packaging/Guidelines|Packaging Guidelines]]

=== Submission to MeeGo ===
* [[Release_Engineering/New_Package_Checklist|Checklist for new package submissions]]
* [[Release_Engineering/Submission_Checklist|Developer's checklist for code submissions]]
* [[Build_Infrastructure/Packagers_Developers#IRC_.2F_mailinglists_.2F_contact|irc / mailing lists / contact]]

== Software Repo ==
* [[Create and update repos]]
* [[Distribution/Package_Management|Package Management]]

== Developer Tools ==
=== Image Creation ===
* [[Image_Creation_For_Beginners|MIC2 for Beginners]]
* [[Image_Creation|MIC2]]
* [[Image Configurations - KickStart Files]]

=== OBS command line ===
* Part 1 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_1|initial setup]]
* Part 2 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|checkout & branch]]
* Part 3 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_4|more commands: localcheckbuild]]

=== Spec tool ===
* [[Spectacle|Spectacle]]

== Distribution Infrastructure ==
* [[Build_Infrastructure|Build Infrastructure - OBS]]
* [[Release_Infrastructure/BOSS|Release Infrastructure - BOSS]]

== Links ==
* [[Release_Engineering|Release Engineering]]
* [[Quality/Compliance|Compliance]]
* [[Quality|Quality]]

Distribution

2011-07-07T13:07:08Z

Kevinwang: /* Image Creation */

This page describes basic information you needed if you want to contribute to MeeGo. Target audience is community member who wish to involve in MeeGo development.

== Package Management and Development ==
=== Overview ===
[[File:Distribution-process-overview-with-obs.png|thumb|250px|right|The development process when using OBS]]
[[File:Distribution-process-without-obs.png|thumb|250px|right|The development process w/o using OBS]]
Like other Linux distros, MeeGo is a package-based system, and it is using [http://www.rpm.org/max-rpm/index.html RPM] package end. The RPM packages are managed in [http://wiki.meego.com/Zypper Zypper] repos. The MeeGo development is using [http://wiki.opensuse.org/Portal:Build_Service Open Build Service (OBS)] to manage and build packages. If you are a serious and frequent MeeGo contributor, you need an OBS account to commit your changes back to MeeGo. Casual contributors can work without using OBS, and submit your changes back into MeeGo through the [http://lists.meego.com/mailman/listinfo mailing list].

The overall processes of development with and without an OBS account are shown in the right figures. Detail description of the processes can be found below.

=== Development with MeeGo OBS account ===
* [[Build_Infrastructure/Packagers_Developers#How_to_get_started|Request a new OBS account]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_1|OBS WebUI: Login and first steps]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_2|OBS WebUI: Link packages and adding a repository]]
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_commandline_client|How to use the command line client for daily operations]]
* [[Build_Infrastructure/Packagers_Developers/Using_OBS_chroot_for_development|Using OBS chroot for development]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]
* [[Build_Infrastructure/Packagers_Developers#Troubleshooting|Troubleshooting]]

=== Development without MeeGo OBS account ===
* [[Local_Build_Without_OBS_Needed|Build and develop packages without OBS ]]
* [[Recompile_kernel | Example: Recompile kernel]]
* [[How to development with multiple packages with dependencies]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]

=== Packaging ===
* [[Packaging/Guidelines|Packaging Guidelines]]

=== Submission to MeeGo ===
* [[Release_Engineering/New_Package_Checklist|Checklist for new package submissions]]
* [[Release_Engineering/Submission_Checklist|Developer's checklist for code submissions]]
* [[Build_Infrastructure/Packagers_Developers#IRC_.2F_mailinglists_.2F_contact|irc / mailing lists / contact]]

== Software Repo ==
* [[Create and update repos]]
* [[Distribution/Package_Management|Package Management]]

== Developer Tools ==
=== Image Creation ===
* [[Image_Creation_For_Beginners|MIC2 for Beginners]]
* [[Image_Creation|MIC2]]
* [[Image Configurations - KickStart Files]]

=== OBS command line ===
* Part 1 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_1|initial setup]]
* Part 2 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|checkout & branch]]
* Part 3 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_4|more commands: localcheckbuild]]

=== Spec tool ===
* [[Spectacle|Spectacle]]

== Distribution Infrastructure ==
* [[Build_Infrastructure|Build Infrastructure - OBS]]
* [[Release_Infrastructure/BOSS|Release Infrastructure - BOSS]]

== Links ==
* [[Release_Engineering|Release Engineering]]
* [[Quality/Compliance|Compliance]]
* [[Quality|Quality]]

Image Creation For Beginners

2011-07-07T13:05:55Z

Kevinwang:

MeeGo Image Creator is the tool we use to create MeeGo images. Here are the simple steps on how to create a MeeGo image.
For more in-depth information, go to the main Image Creator developer's guide: [[Image Creation]]
__TOC__
== Creating a MeeGo Image ==

===STEP 1 - Install Meego Image Creator (MIC)===

To install it:
* on OpenSuse
sudo zypper addrepo http://repo.meego.com/MeeGo/tools/repos/opensuse/11.4/ meego-tools
sudo zypper install mic2
* on Fedora
add repo like this:
# cat <<REPO > /etc/yum.repos.d/meego-tools.repo
[meego-tools]
name=MeeGo Tools for Fedora
baseurl=http://repo.meego.com/MeeGo/tools/repos/fedora/\$releasever
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-meego
REPO
add gpg key:
# gpg2 --keyserver subkeys.pgp.net --recv 0BC7BEC479FC1F8A
# gpg2 --export --armor 0BC7BEC479FC1F8A > /etc/pki/rpm-gpg/RPM-GPG-KEY-meego
Install mic2:
# yum install mic2
* on MeeGo
sudo zypper addrepo http://repo.meego.com/MeeGo/tools/repos/meego/1.1/ meego-tools
sudo zypper install mic2
* on Ubuntu or Debian:
For Ubuntu 10.10, add the below line to /etc/apt/sources.list
deb http://repo.meego.com/MeeGo/tools/repos/ubuntu/10.10/ /
For Debian 5.0, add the below line to /etc/apt/sources.list
deb http://repo.meego.com/MeeGo/tools/repos/debian/5.0/ /
Install mic2:
$sudo apt-get update
$sudo apt-get install mic2
* Download MIC source from Gitorious:
http://meego.gitorious.org/meego-developer-tools/image-creator

More on installation dependencies and options on downloading MIC, go to the 'Installation' section here: [[Image_Creation#Installation_Requirements]]

===STEP 2 - Get MeeGo .ks File===

KickStart (.ks) configuration files are passed to MIC to create images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

The official MeeGo .ks files are here:

Formal release: http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build: http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the MeeGo images you create. Modify these .ks files as you wish to create tailored images.

For details about how to modify the ks file, please refer: http://wiki.meego.com/Image_Configurations_-_KickStart_Files

===STEP 3 - Create MeeGo Livecd Image===

MIC has to be run with root privileges using 'sudo'.

Here is the command to create a MeeGo livecd image you can burn onto a CD.

<pre>
sudo mic-image-creator --config=default.ks --format=livecd --cache=mycache
</pre>

A file named meego-1.2-default-XX.iso is created. This ISO image is a hybrid image and can be either written to a disk device or burned onto a cd.

===STEP 4 - Create MeeGo LiveUSB Image===

To create a MeeGo liveusb image that you can transfer to a USB stick.

<pre>
sudo mic-image-creator --config=default.ks --format=liveusb --cache=mycache
</pre>

A file named meego-1.2-default-XX.usbimg will be created. To burn it onto a USB stick, run the following command:

<pre>
sudo mic-image-writer meego-1.2-default-XX.usbimg
</pre>

This image has a FAT file system and can be mounted easily on Windows and other OSes.

'''---FOR ADDITIONAL INFORMATION ON MIC, PLEASE VISIT THE MIC DEVELOPER'S GUIDE HERE: [[Image Creation]]---'''

== Configure Proxy and Other Variables ==

~/.mic2.conf is a configuration file that can make your life easier by specifying proxy settings, cache directories, and other variables that you normally would have to re-type in your command-line.

Copy and paste this into a file called: ~/.mic2.conf

Replace with your own relevant values.

<pre>
[main]
cachedir=/home/user1/mycache
tmpdir=/home/user1/mystorage/tmp
outdir=/home/user1/mystorage
proxy=http://my.proxy.com:911/
no_proxy=localhost,127.0.0.0/8,.mysite.com,172.16.0.0/16
</pre>

''cachedir'' = directory where the cached repo(s) will reside. With this variable set, you do not need to pass the --cache flag in the command-line.

''tmpdir'' = temporary directory used by mic2 when creating images. With this variable set, you do not need to pass the --tmpdir flag in the command-line.

''outdir'' = where your images will reside once they are created. With this variable set, you do not need to pass the --outdir flag in the command-line.

''proxy'' = specify your proxy if you're behind a behind a firewall.

''no_proxy'' = specify what domains should not sure the proxy setting.

'''Note:''' When specifying proxy and no_proxy, you do not need to use the --proxy flag in your .ks files when referring to repos.

'''---FOR ADDITIONAL INFORMATION ON MIC, PLEASE VISIT THE MIC DEVELOPER'S GUIDE HERE: [[Image_Creation]]---'''

Another language version of this page

* [[适合新手的镜像制作-_-简体中文]]

Image Creation

2011-07-07T12:38:40Z

Kevinwang:

This is the main Image Creator developer's guide. For a more simplistic, step-by-step document, go to: [[Image Creation For Beginners]].

= Overview =

The tool used to create MeeGo images is called "MIC2" (to distinguish from obsolete MIC - Moblin Image Creator). MIC is composed of a series of tools to create images, convert images, chroot, etc. MIC2 is primarily based on Fedora livecd-tools and appliance-tools.

With MIC2 tools, users can create different types of images for different purposes, including live CD images, live USB images, raw images for KVM, VMDK images for Vmware, vdi images for VirtualBox, loop images for IVI platforms, NAND images for Moorestown platforms, ubi images for N900, fs image for MeeGo developers. Also, users can use MIC2 tools to manipulate images, like transforming an image from a virtual machine to a live image, and providing a chroot environment based on an existing live image. With these features, developers can do development work on a host virtual machine running MeeGo or a Meego chroot environment, and transfer the resulting new live image to a target device for final debug/verification.

= Features =

MIC2 offers these major tools:
* mic-image-creator: create images.
* mic-image-convertor: convert a raw/vmdk/vdi/live image into a live image.
* mic-chroot: provide a MeeGo environment from a live/loop image for development, it also can translate that chroot file system into a live image.
* mic-image-writer: write a MeeGo image to a USB disk. This is a safe alternative to dd.

The following support is provided:

* Supports mainstream Linux distros. MIC2 has been thoroughly tested on these distributions:
** Meego
** Fedora (Fedora 13 and above)
** Opensuse (> OpenSUSE 11.3)
** Ubuntu > 10.04
* Supports various types of images: livecd, liveusb, loop, raw, vmdk, nandmrst, vdi, fs, ubi
* Supports image coversion from virtual machine/live images to live images.
* Uses kickstart (.ks) files for image creation. Through this, users can specify which software repositories to use, which packages to install, and basic system configuration directives. Please refer to http://fedoraproject.org/wiki/Anaconda/Kickstart for more information about kickstart configuration files.

= Usage =
== Installation ==

We currently build MIC2 binary rpms/debs for many popular Linux distributions, including Fedora 13, Fedora 14, Fedora15, Ubuntu 10.04, Ubuntu 10.10, OpenSUSE 11.3, OpenSUSE 11.4, and Debian 5.0. Please go to http://repo.meego.com/tools/repos/ to get a repository URL corresponding to your Linux distribution, then add it into your repo or package source for installation and update later. If your distribution isn't in the support list, please install MIC2 from git source.

=== Installation Requirements ===

To use MIC2, your host machine (that will run mic2) must have Intel* Atom* or Intel* Core* 2 CPU (support for SSSE3), this is a hard requirement (ARM image is exceptional).

On Fedora, openSUSE and MeeGo, mic2 depends directly on the following packages (they will be automatically installed on installing mic2):

* util-linux
* coreutils
* python >= 2.5
* e2fsprogs
* dosfstools >= 2.11-8
* yum >= 3.2.24
* pykickstart >= 0.96
* python-iniparse
* syslinux >= 3.82
* curl
* kpartx
* parted
* device-mapper
* zlib
* rsync
* /usr/bin/mkisofs
* wget
* cpio
* isomd5sum
* gzip
* bzip2
* squashfs-tools >= 4.0
* btrfs-progs
* python-zypp >= 0.5.7

On Debian and Ubuntu, mic2 depends on or recommands or suggests the following packages (they will be automatically installed if possible on installing mic2):

Depends:

* bzip2
* curl
* dbus
* dmsetup
* dosfstools
* e2fsprogs (>= 1.41),
* genisoimage
* kpartx
* parted
* psmisc
* python-iniparse
* python-pykickstart (>= 0.96) | pykickstart (>= 0.96),
* python-urlgrabber
* rsync
* squashfs-tools (>= 4.0)
* syslinux (>= 3.82)
* yum (>= 3.2)

Recommends:

* binfmt-support
* btrfs-tools
* extlinux
* qemu-user-static
* udisks | hal

Suggests:

* python-zypp

For source installation, these two packages are necessary:

* zlib-devel(for compiling)
* python-devel(for installation)

You should load these modules, as well, if they're not loaded automatically by the kernel:
 (Use <code>lsmod</code> to list modules.)

* squashfs
* squashfs-tools
* dm_snapshot
* loop

Specific packages for Ubuntu 8.10:

* python-celementtree
* python-elementtree
* dmsetup

=== Installing requirements for Ubuntu 10.10 ===

sudo apt-get install yum rpm kpartx parted syslinux isomd5sum kvm zlib1g-dev squashfs-tools python2.6-dev qemu-arm-static python-urlgrabber

=== Binary Package installation ===

* '''Installation Steps For Fedora 13, Fedora 14, and Fedora 15'''

1. Add MIC2 repo as user root:

<pre>
# cat <<REPO > /etc/yum.repos.d/meego-tools.repo
[meego-tools]
name=MeeGo Tools for Fedora
baseurl=http://repo.meego.com/MeeGo/tools/repos/fedora/\$releasever
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-meego
REPO
</pre>

2. Add gpg key as user root:

<pre>
# gpg2 --keyserver subkeys.pgp.net --recv 0BC7BEC479FC1F8A
# gpg2 --export --armor 0BC7BEC479FC1F8A > /etc/pki/rpm-gpg/RPM-GPG-KEY-meego
</pre>

3. Install mic2 as user root:
<pre>
# yum install mic2
</pre>

if you get asked to import the key do so:
<pre>
warning: rpmts_HdrFromFdno: Header V3 DSA/SHA1 Signature, key ID 79fc1f8a: NOKEY
meego-fedora/gpgkey | 3.3 kB 00:00 ...
Importing GPG key 0x79FC1F8A:
Userid: "Moblin Build (Moblin Build User) <build@moblin.org>"
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-meego
Is this ok [y/N]: y
</pre>

* '''Update Steps For Fedora 13, Fedora 14, and Fedora 15'''

You can use the below command to get the latest mic2 package.

<pre>
# yum update mic2
</pre>

* '''Installation Steps For Ubuntu 10.04, Ubuntu 10.10, and Debian 5.0'''

1. Add package source

For Ubuntu 10.04, add the below line to /etc/apt/sources.list

<pre>
deb http://repo.meego.com/MeeGo/tools/repos/ubuntu/10.04/ /
</pre>

For Ubuntu 10.10, add the below line to /etc/apt/sources.list

<pre>
deb http://repo.meego.com/MeeGo/tools/repos/ubuntu/10.10/ /
</pre>

For Debian 5.0, add the below line to /etc/apt/sources.list

<pre>
deb http://repo.meego.com/MeeGo/tools/repos/debian/5.0/ /
</pre>

mic2 is also available in Debian Testing, which will become Debian 6.0.

2. sudo apt-get update

You should see the following error:
W: GPG error: http://repo.meego.com Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0BC7BEC479FC1F8A

To add the repository public key use the following command:
:gpg --keyserver subkeys.pgp.net --recv 0BC7BEC479FC1F8A
:gpg --export --armor 0BC7BEC479FC1F8A | sudo apt-key add -

Note: Often the port used by gpg is blocked in companies, so gpg will time out. You can install it manually; this example is for Ubuntu 10.10:
:wget http://repo.meego.com/MeeGo/tools/repos/ubuntu/10.10/Release.key
Open System->Administrator->Software Sources. Under the Authentication tab, import the key.

Now redo sudo apt-get update

3. sudo apt-get install mic2

* '''Installation Steps For OpenSUSE 11.3, and OpenSUSE 11.4'''

1. Add repos

For OpenSUSE 11.3:

<pre>sudo zypper addrepo http://repo.meego.com/MeeGo/tools/repos/opensuse/11.3/ meego-tools</pre>

For OpenSUSE 11.4:

<pre>sudo zypper addrepo http://repo.meego.com/MeeGo/tools/repos/opensuse/11.4/ meego-tools</pre>

2. sudo zypper install mic2

* '''Install Steps For OpenSUSE 11.3, and OpenSUSE 11.4'''

<pre>
sudo zypper install mic2
</pre>

=== From Stable Git Source Releases ===

You can get the latest stable release of MIC2 from the tag section in http://meego.gitorious.org/meego-developer-tools/image-creator. Click on the "Source tree" link on the top of the screen. There will be a list of tags on the right hand side.

You should follow the below steps to install it:

<pre>
git clone git://gitorious.org/meego-developer-tools/image-creator.git
cd image-creator
git checkout 0.17 #check Gitorious for the most recent tag
make
sudo make install
</pre>

=== From Development Git Tree ===

Note: MIC2 GIT tree has latest-and-greatest source, so stability is not guaranteed. If you run into errors, please use a 'Stable Release' instead before filing a bug.

You need to follow the below steps to git clone MIC2:

<pre>
git clone git://gitorious.org/meego-developer-tools/image-creator.git
</pre>

Build and install:

<pre>
cd image-creator
make clean
make
sudo make install
</pre>

You should add the repo for mic2 then run

<pre>
sudo ./tools/mic-check-alldeps
</pre>

to check/install all the depended packages, otherwise mic2 can't work normally.

== Proxy Setting ==

If you need to use proxy to access Internet, you must set proxy for mic2 correctly. Generally, you should export these environment variables:

<pre>
$ export http_proxy="http://proxy.yourcompany.com:8888"
$ export https_proxy="http://proxy.yourcompany.com:8888"
$ export no_proxy="127.0.0.0/8, .yourcompany.com"
</pre>

If you use sudo to run mic2, you also need to add these into /etc/sudoers in order that they still are valid after sudo.

<pre>
$ sudo visudo

Add: Defaults env_keep += " no_proxy http_proxy https_proxy"
</pre>

so sudo will adhere to the no_proxy and proxy settings.

You also can set proxy in /etc/mic2/mic2.conf or in ~/.mic2.conf by adding the below two lines:

<pre>
proxy=http://proxy.yourcompany.com:8888/
no_proxy=localhost,127.0.0.0/8,.yourcompany.com
</pre>

Of course, you need to change proxy.yourcompany.com:8888 and .yourcompany.com according to your network.

From mic2 0.23.0 on, mic2 enabled zypp backend, it uses /etc/sysconfig/proxy to get proxy settings, so you also need to create this file (it is a system file in OpenSUSE, so for openSUSE, you just set correct values inside of it) if you need to use proxy to access internet. Here is a sample:

<pre>
#### /etc/sysconfig/proxy sample ####
## Path: Network/Proxy
## Description:
## Type: yesno
## Default: no
## Config: kde,profiles
#
# Enable a generation of the proxy settings to the profile.
# This setting allows to turn the proxy on and off while
# preserving the particular proxy setup.
#
PROXY_ENABLED="yes"

## Type: string
## Default: ""
#
# Some programs (e.g. lynx, arena and wget) support proxies, if set in
# the environment. SuSEconfig can add these environment variables to
# /etc/SuSEconfig/* (sourced by /etc/profile etc.) -
# See http://portal.suse.com/sdb/en/1998/01/lynx_proxy.html for more details.
# Example: HTTP_PROXY="http://proxy.provider.de:3128/"
HTTP_PROXY="http://proxy.yourcompany.com:8888/"

## Type: string
## Default: ""
#
# Some programs (e.g. lynx, arena and wget) support proxies, if set in
# the environment. SuSEconfig can add these environment variables to
# /etc/SuSEconfig/* (sourced by /etc/profile etc.) -
# this setting is for https connections
HTTPS_PROXY="http://proxy.yourcompany.com:8888/"

## Type: string
## Default: ""
#
# Example: FTP_PROXY="http://proxy.provider.de:3128/"
#
FTP_PROXY="http://proxy.yourcompany.com:8888/"

## Type: string
## Default: ""
#
# Example: GOPHER_PROXY="http://proxy.provider.de:3128/"
#
GOPHER_PROXY=""

## Type: string(localhost)
## Default: localhost
#
# Example: NO_PROXY="www.me.de, do.main, localhost"
#
NO_PROXY="localhost, 127.0.0.1, .yourcompany.com"

#### /etc/sysconfig/proxy sample ####
</pre>

You need to change proxy.yourcompany.com:8888 and .yourcompany.com according to your network. By default, zypp will be used, but you can use option --pkgmgr=yum to force mic2 to use yum, you can do so if you find zypp can't work for you, but remember to file a bug on http://bugs.meego.com/enter_bug.cgi?product=Development%20Tools&component=MIC%20(Image%20Creator) if you find any issue related to zypp.

An option --proxy for repo command in kickstart file also can set proxy, you can specify it as follows:

<pre>
repo --name=meego --baseurl=http://repo.meego.com/trunk/repo/ia32/os/ --proxy=http://proxyhost:proxyport/
</pre>

You also need to add two more options to repo if your proxy needs user authentication:

<pre>
repo --name=meego --baseurl=http://repo.meego.com/trunk/repo/ia32/os/ --proxy=http://proxyhost:proxyport/ --proxyuser=proxyusername --proxypaswd=proxyuserpassword
</pre>

== Running mic-image-creator ==

Configuration of images is based on kickstart, the format used for unattended installation in Fedora and Redhat.

Super user privileges are needed. The tool is more or less self-documented, use the --help option to see options.
<pre>
sudo mic-image-creator --help
</pre>

=== Creating Supported Image Types ===

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

creating arm images needs 'qemu-arm' os 'qemu-arm-static' command available, and creating vdi or vmdk images needs 'vboxmanager' available, so be sure your system have installed them before creating these types of images.

To obtain the official Meego .ks files, go here: http://wiki.meego.com/Image_Creation#Official_Meego_.ks_files

'''Create ARMv7 Images'''

When creating images for ARMv7 hardware, pass ''--arch=armv7hl'' to ''mic-image-creator'' commands.

'''Create Livecd Image'''

<pre>
sudo mic-image-creator --config=default.ks --format=livecd --cache=mycache
</pre>

This tells image-creator to use the kickstart file default.ks to obtain info about which packages to download and include in the image, and --cache is the directory on your local machine which will host a cache of these packages. The cache is very useful if you are remote to the server and reduces the amount of downloaded packages next time you create an image. Next time the command is run, this cache will simply be 'updated' if there are changes, rather than re-downloading from the repositories again.

The output of this command will be a file named meego-1.2-default-XX.iso created. This ISO image is a hybrid image and can be either written to a disk device or burned onto a cd.

To burn it onto a USB stick, just run the following command, assuming the USB stick is /dev/sdb in your system:

<pre>
sudo mic-image-writer meego-1.2-default-XX.iso
</pre>

'''Create Moorestown NAND Image'''

<pre>
sudo mic-image-creator --config=default.ks --format=mrstnand

remove the first 512 bytes from the image to remove the partition information.
sudo dd bs=512 skip=1 if=meego-1.2-default-XX-sda.bin of= meego-1.2-default-XX-nand.img
</pre>

'''Create Liveusb Image'''

<pre>
sudo mic-image-creator --config=default.ks --format=liveusb --cache=mycache
</pre>

A file named meego-1.0-default-XX.usbimg will be created. To burn it onto a USB stick, run the following command, assuming the USB stick is /dev/sdb in your system:

<pre>
sudo mic-image-writer meego-1.2-default-XX.usbimg
</pre>

This image has a FAT file system and can be mounted easily on Windows and other OSes.

'''Create Liveusb Image Interactively'''

<pre>
sudo mic-image-creator --config=default.ks --format=liveusb --interactive --cache=mycache
</pre>

It directly creates a MeeGo live usb stick.

Liveusb image can be created in two different ways, interactive and non-interactive (default). When running MIC2 in a non-interactive mode, MIC2 creates a USB images file that can be copied directly into a USB stick. The non-interactive mode can be used for daily build or automated testing. The interactive mode will write the images onto a USB disk, it will detect if a USB stick is available and detects and verifies a partition is available. If two or more USB devices are present, you will be asked to select the target device. This way the contents of the existing USB stick won't be destroyed unless no appropriate partition is found, end user should use it to create the live USB.

'''Create Loop Image'''

This is the simplest image format available. Such images can be loop mounted and chrooted into, for example, to build applications or for debugging purposes.

<pre>
sudo mic-image-creator --config=default.ks --format=loop --cache=mycache
</pre>

A file named meego-1.2-default-XX.img is created. You can use below to mount it and chroot into it.

<pre>
sudo mount -o loop meego-1.2-default-XX.img /mnt
sudo chroot /mnt su -
</pre>

'''Create KVM Image'''

Can be used with QEMU or other VMM applications to launch MeeGo as a virtualized instance.

<pre>
sudo mic-image-creator --config=default.ks --format=raw --cache=mycache
</pre>

A file named meego-1.2-default-XX folder with a meego-1.2-default-XX-sda.raw image is created. For optimal results, use this feature in a machine with VT support and enable it in the BIOS.

If you use Fedora or openSUSE, run the following command to launch the image into MeeGo KVM virtual machine:

<pre>
sudo qemu-kvm -m 512 -boot c -hda meego-1.2-default-XX-sda.raw -std-vga
</pre>

If you use Ubuntu, run the following command launch image:

<pre>
sudo kvm -m 512 -boot c -hda meego-1.2-default-XX-sda.raw
</pre>

'''Create VMDK Image'''

VMDK images can be loaded into Vmware or Vmware player. MIC2 also generates a VMX file that has image configuration and can be used to launch the image in Vmware by just clicking the file. If you have vmplayer, it should open automatically.

<pre>
sudo mic-image-creator --config=default.ks --format=vmdk --cache=mycache
</pre>

A file named meego-1.2-default-XX folder with both meego-1.2-default-XX-sda.vmdk image and meego-1.2-default-XX-sda.vmx is created. Just run vmware or vmware player, and select the generated vmx file.

=== KickStart Files (configuration files used for image creation) ===

* [[Image Configurations - KickStart Files]]

=== MIC2 Configuration file ===

MIC2 options can be specified in a global configuration file ('''/etc/mic2/mic2.conf''') and local configuration file ('''$HOME/.mic2.conf'''), where you can specify:
* Repository configuration
* proxy settings
* cache directories and
* other variables
that you normally would have to re-type in your command-line.

The two configuration files have the same format, /etc/mic2/mic2.conf is global, no matter whoever is running MIC2, this configuration file will be read first, $HOME/.mic2.conf is just valid for current user, every user can have their own settings.
The final configuration is a combination of two configuration files, options in '''$HOME/.mic2.conf''' will override those from '''/etc/mic2/mic2.conf'''. Options from command line have the highest priority.
If an option is specified on the command line, the same option in both configuration files, global and local will be ignored.

Below is an example you can cut-and-paste, and reuse for your needs:

<pre>
[main]
cachedir=/home/user1/mycache
tmpdir=/home/user1/mystorage/tmp
outdir=/home/user1/mystorage
proxy=http://my.proxy.com:911/
no_proxy=localhost,127.0.0.0/8,.mysite.com,172.16.0.0/16
</pre>

''cachedir'' = directory where the cached repo(s) will reside. With this variable set, you do not need to pass the --cache flag in the command-line.

''tmpdir'' = temporary directory used by MIC2 when creating images. With this variable set, you do not need to pass the --tmpdir flag in the command-line.

''outdir'' = where your images will reside once they are created. With this variable set, you do not need to pass the --outdir flag in the command-line.

''proxy'' = specify your proxy if you're behind a behind a firewall.

''no_proxy'' = specify what domains should not sure the proxy setting.

''image_format'' = specify image format.

''default_ks'' = specify a default kickstart file, there are several kickstart files provided in repository http://repo.meego.com/MeeGo/devel/trunk/repo/ia32/os/

'''Note:''' When specifying proxy and no_proxy, you do not need to use the --proxy flag in your .ks files when referring to repos.

In configuration files, you also can specify one or multiple repositories, for example:

<pre>
[trunk]
name=trunk
baseurl=http://repo.meego.com/MeeGo/devel/trunk/repo/ia32/os/
enabled=1
</pre>

Once there is this repository info in your configuration files, and both image_format and default_ks are set, you can just run "sudo mic-image-creator" to create a image, there isn't any extra argument needed.

=== Use Bootstrap ===

MIC2 highly depends on yum and librpm, but different Linux distributions used diffrent yum and librpm versions, so MIC2 has some compatibility issues on OpenSUSE, Ubuntu and Debian, bootstrap is just for fixing these compatibility issues.

bootstrap is a minimal MeeGo file system, MIC2 can run very smoothly on it using chroot mode. You can use the below command to create a bootstrap:

<pre>
sudo mic-create-bootstrap -n trunk -k /your/repo/cache/path -r http://repo.meego.com/MeeGo/builds/trunk/latest/repos/oss/ia32/packages/ -o /your/final/bootstrap
</pre>

NOTE: The repo-url specific for your needs may differ

-n is used to specify repository name, if you have its cache before, it can reduce runtime dramatically to use it with -k option, -k is used to specify your repository cache dir, -r is used to specify MeeGo main repository.

Once you created your bootstrap, you can use this bootstrap to run MIC2 as follows

<pre>
sudo mic-image-creator --bootstrap=/your/final/bootstrap --format=livecd --config=default.ks --cache=/your/repo/cache/path
</pre>

Alternatively, you can create and use bootstrap in one mic-image-creator run, as follows

<pre>
sudo mic-image-creator --build-bootstrap --bootstrap=/your/final/bootstrap --format=livecd --config=default.ks --cache=/your/repo/cache/path
</pre>

== Running mic-image-writer ==

mic-image-writer writes a Meego image to a USB disk as an alternative to dd.

mic-image-writer can run in both console mode and GUI mode. It can decide which mode to run, according to current system environment. You can also use a given option to force it to run in some other mode. Run 'mic-image-writer --help' to get usage information:

<pre>
Usage: mic-image-writer [options] [image file]

Options:
-h, --help Show this help message and exit
-c, --console Run in console mode
-g, --gui Run in GUI mod
</pre>
Here is a run example in console mode:

<pre>
$ sudo mic-image-writer meego-xxx.img
Available usb disk:
[1] /dev/sdc: SanDisk USB Flash Drive
[2] /dev/sdb: SanDisk U3 Cruzer Micro
Please choice [1..2] ? 2
Source: /myhome/meego-xxx.img
Target: /dev/sdb
Image size: 559 MB
Estimated time: 55 seconds
Elapsed time: 64, progress: 100% 8944+0 records in
8944+0 records out
586153984 bytes (586 MB) copied, 63.0486 s, 9.3 MB/s
</pre>

mic-image-writer can estimate how long it will take to write the given image to your USB disk and reports current writing progress. It automatically unmounts your USB disk, if it is mounted. If your USB can't be unmounted, it will terminate.

If you love UI mode, you can run it in X enviroment. The command with the added -g flag:

<pre>
sudo mic-image-writer -g meego-xxx.img
</pre>

Image name is optional.

== Running mic-image-convertor ==

It's very easy to use:

<pre>
sudo mic-image-convertor --source-image=InputImage --target-format=Targegformat

sudo mic-image-convertor -I InputImage -T Targegformat
</pre>

For example, to translate a KVM raw image to livecd image, just type:

<pre>
sudo mic-image-convertor --source-image=meego-core-200902200545/meego-core-200902200545-sda.raw --target-format=livecd
</pre>

A new livecd image of meego-converted-from-raw-200902201804.iso is generated. The tool can detect the type of input image, either raw or vmdk.

This tool is very useful. For example, the developer can launch a virtual machine running MeeGo v2 and make whatever changes on the virtual system like yum install/remove a package, scp a source tarball to VM and build and try, and etc. Then with a simple "sync" or shutdown of VM, the VM image now contains his changes. With this tool, the VM image can be transformed to a live image and burned to a USB flash disk. Now developers can have final verifications in a target device, with changes in the live system.

== Running mic-chroot ==

There are two major usage models for mic-chroot for developers.

'''chroot directly into the image to use it as a development environment, then optionally create a new image based off of your changes'''
<pre>
sudo mic-chroot -c livecd meego-core-200903131337.iso
</pre>

The above command would present a chroot, using the livecd image, to developers with some bind mounts like /proc /sys /dev/pts and /parentroot. With those bind mounts, developers now can easily exchange files in chroot env with host /parentroot, and conduct yum install, yum remove and any other network related operations. After done and typing "exit", a new live ISO image is created from the chroot env with the changes developers made.

'''Unpack and modify the image's filesystem (which you can save), and create a new image based off of your changes'''

Sometimes, developers want to keep the chroot env, so that they can do multiple changes in that root file system at different times. So they want to execute following:

<pre>
sudo mic-chroot -s my-chroot-fs --unpack-only meego-core-200903131337.iso --bind-mounts=/proc:/proc;/:/parentroot;/sys:/sys;/dev/pts:/dev/pts
</pre>

The above command creates a folder called 'my-chroot-fs' in the current directory, using the chroot environment from the livecd image. Of course, if one forgets to add the --bind-mounts options, you'll need to manually do the bind mounting yourself. Don't forget copying /etc/reslov.conf into my-chroot-fs if you need to use DNS. Should you wish to create an image from the chroot, just execute following to create a livecd image

<pre>
sudo mic-chroot -c livecd --convert-only my-chroot-fs/
</pre>

== Enabling Autoinstallation ==

You need to copy a kickstart file into /root/mic2-ks.cfg which is used for
automated installation of the image. To activate autoinstall mode, boot with autoinst on the command line
or add --menus=autoinst to the bootloader directive in the kickstart file you use to
create the image.

= Development Release Processes =

http://wiki.meego.com/MIC2_Development_Release_Processes

= Known issues =

* MIC2 is not compatible with Ubuntu 8.04 (Yum package compatibility)
* MIC2 is not compatible with the initial Ubuntu 9.04. Make sure you have package libsqlite3-0 of 3.6.10-1ubuntu0.2 or later.
* MIC2 has some issues on Debian, please refer to [[MIC on Debian]] to get installation instructions

= Troubleshooting =

You can file a bug on http://bugzilla.meego.com/enter_bug.cgi?product=Development%20Tools (Note: you should select MIC for component) if you run into any MIC2-related issue, bugzilla can track your issue faster and more efficiently.

===libgcc related issues===
<pre>
libgcc_s.so.1 must be installed for pthread_cancel to work"

"Error: failed to create image : '/sbin/mksquashfs /var/tmp/imgcreate-FKCSsk/iso-u8xCPh/LiveOS/osmin /var/tmp/imgcreate-FKCSsk/iso-u8xCPh/LiveOS/osmin.img' exited with error (-6)
</pre>

This error occurs when MIC2 is unable to find the proper version of libgcc. This usually happens on x86_64 systems - MIC2 is looking for the 32 bit version of libgcc, but only the 64 bit version is installed. Installing the 32 bit version of libgcc should resolve this.

===General squashfs issues===
<pre>
"Error: failed to create image : '/sbin/mksquashfs /var/tmp/imgcreate-FKCSsk/iso-u8xCPh/LiveOS/osmin /var/tmp/imgcreate-FKCSsk/iso-u8xCPh/LiveOS/osmin.img' exited with error (-6)
</pre>

This error can also be an issue with the syslinux package. Try updating to the latest version for your distro.

===device-mapper issues===
<pre>
unable to remove open device
</pre>

This is a race condition with device-mapper in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=506644. Usually rerunning the MIC2 command will resolve this.

===python related issues===
<pre>
from urlgrabber.grabber import URLGrabber
ImportError: No module named urlgrabber.grabber
</pre>

Some people are using python they built themselves, so some python modules aren't under their python library path. For such error, only one way is not to use your own python but to use python your system installed.

===debian-based distros related issues===
On debian-based distros, we used pycentral to package mic2, but mic2 source installtion used distutils, so two kinds of installation have different installation path, if they exist there at the same time, it will result in some unpredictable errors to run mic2. To run it correctly, you can keep only one installation, source or binary.

Remove binary installation
<pre>
sudo apt-get remove mic2
</pre>

Remove source installation

Get python lib path
<pre>
$ python
Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38)
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import distutils.sysconfig
>>> print distutils.sysconfig.get_python_lib()
<PYTHONLIBPATH>
>>>
$
</pre>

Remove mic2 files
<pre>
$ sudo rm -rf <PYTHONLIBPATH>/mic
$ sudo rm -rf <PYTHONLIBPATH>/mic-0.*
$ sudo rm -f /usr/bin/mic
$ sudo rm -f /usr/bin/mic-*
$ sudo rm -f /usr/bin/moblin-*
</pre>

Note: You must replace <PYTHONLIBPATH> with the above python lib path

If program jams after mkfs.vfat, it might be due missing ''vol_id'' program. ''vol_id'' is replaced with ''blkid'' in new ubuntu versions. Try run ''/lib/udev/vol_id'', if it's missing you have troubles.

===ARM related issues===
<pre>
Traceback (most recent call last):
File "/usr/bin/mic-image-creator", line 856, in <module>
ret = main()
File "/usr/bin/mic-image-creator", line 682, in main
run_in_bootstrap(options.bootstrap, argv, bindmounts, arch = options.arch)
File "/usr/bin/mic-image-creator", line 261, in run_in_bootstrap
ret = subprocess.call(args, preexec_fn = chroot_bootstrap)
File "/usr/lib/python2.5/subprocess.py", line 444, in call
return Popen(*popenargs, **kwargs).wait()
File "/usr/lib/python2.5/subprocess.py", line 594, in __init__
errread, errwrite)
File "/usr/lib/python2.5/subprocess.py", line 1149, in _execute_child
raise child_exception
OSError: [Errno 8] Exec format error
</pre>

This error occurs when trying to build ARM images without passing ''--arch=armv7l'' to ''meego-image-creator''.

<pre>
Error: Requires qemu version >= 0.13 for armv7hl
</pre>

you should update the version of 'qemu-arm' or 'qemu-arm-static' to 0.13.0 or above.

Tips: if you encounter arm images creating failed, please try to run bootstrap mode, for armv7hl and armv7nhl is not supported in legacy mode.

===Proxy cache===

See http://bugs.meego.com/show_bug.cgi?id=2343

Some servers (such as with squid as a proxy) may cache more aggressively than
others, and as a result repomd.xml is invalid (old copy) and
references out of date metadata files (primary, comps, filelists, etc). This is
because the server is returning a cached/old copy of repomd.xml.

Proxy cache should be disabled in mic and yum.

= Advanced Hacking Tips =

===replace kernel in live image===

<pre>
$sudo mic-image-convertor --source-image=<your-netbook.img> --target-format=livecd --shell
</pre>

This command will give you a chroot environment of MeeGo, you can follow the below steps to replace the default kernel with a new one.

1). remove the old kernel

<pre>
# rpm -e kernel-netbook
</pre>

NOTE: execute the above command in chroot environment.

2). copy new kernel to chroot environment of MeeGo

<pre>
$sudo cp /path/to/kernel-*.rpm /var/tmp/imgcreate-*/install_root/
</pre>

NOTE: execute the above command in your host system.

/path/to/kernel-*.rpm is your new kernel to install, /var/tmp/imgcreate-*/install_root/ is the directory where chroot MeeGo mounted on.

3). install the new kernel

<pre>
# rpm -ivh /kernel-*.rpm
# rm /kernel-*.rpm
</pre>

NOTE: execute the above command in chroot environment.

After that, you can find out the new kernel in directory /boot/.

4). update contents of isolinux

<pre>
$sudo cp /var/tmp/imgcreate-*/install_root/boot/initrd-*.img /var/tmp/imgcreate-*/iso-*/isolinux/initrd0.img
$sudo cp /var/tmp/imgcreate-*/install_root/boot/vmlinuz-* /var/tmp/imgcreate-*/iso-*/isolinux/vmlinuz0
</pre>

NOTE: execute the above command in your host system.

5. create a new image
<pre>
#exit
</pre>
NOTE: execute the above command in chroot environment.

After following all the above steps, you'll have a new image.

===build btrfs image===
From version 0.20.1 on, mic2 can support btrfs, you can create btrfs image by change fstype=ext3 in your kickstart file to fstype=btrfs. A successful creation will depend on btrfs-progs (btrfs-tools on debian-based distros, btrfsprogs on openSUSE) and btrfs kernel module in your local system, the known issue is we can't create btrfs image on Fedora 11, the issue is the default btrfs kernel module has some issue which will make kernel panic, so for this case, you must make sure you have a stable and latest kernel and btrfs-progs 0.19 on your system. You'll need to build your kernel by yourself and use it to boot your system.

Btrfs-progs is a prerequisite tool, it includes /sbin/mkfs.btrfs, but its version must match btrfs kernel module, so you must ensure this, mic2 repo http://repo.meego.com/MeeGo/tools/repos/ has an issue which will install btrfs-progs 0.19 when you install mic2, this is an repo sync error, so please make sure you have your distro's btrfs-progs after mic2 is installed, if your distro's btrfs-progs version is 0.19, this isn't an issue, otherwise you must remove btrfs-progs installation introduced by mic2 and reinstall your distro's btrfs-progs.

How to build btrfs image on Fedora 11 or lower version?

# Download kernel-2.6.34 or kernel-2.6.35
# Configure btrfs as module
# make; make modules; make install; make modules_install
# Reboot your system using this built-newly kernel
# Install btrfs-progs 0.19

Done, you're ready for creating btrfs image.

===Metapackages, Patterns, and Repository Creation===
Meta-packages are discouraged in MeeGo. The preferred method is to use patterns in the repository (supported by both zypper and mic2). This is done by creating a patterns.xml file, which is a fairly simple XML file:

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<pattern xmlns:rpm="http://linux.duke.edu/metadata/rpm"
xmlns="http://novell.com/package/metadata/suse/pattern">
<name>meego-core</name>
<summary>MeeGo Core</summary>
<description>Packages needed for Compliance</description>
<uservisible/>
<category lang="en">Base Group</category>
<rpm:requires>
<rpm:entry name="pam"/>
<rpm:entry name="rootfiles"/>
<rpm:entry name="bash"/>
<rpm:entry name="sysvinit"/>

</rpm:requires>
</pattern>
</pre>

The detailed documentation for this XML schema may be found on the [http://en.opensuse.org/openSUSE:Standards_Rpm_Metadata OpenSuSe Wiki]. There is also a Relax NG schema found in the source code for [http://gitorious.org/opensuse/libzypp libzypp] (buried in the folder zypp/parser/yum/schema).

In MeeGo's [http://meego.gitorious.org/meego-os-base/package-groups package-groups], you can find several utilities, style sheets, and examples for how to create patterns and convert them to groups (comps).

Once you have both a patterns.xml and comps.xml file, you can create your repository like this. (For brevity, assuming a simple 'packages' repository.)

<code>
## Copy RPM packages to a folder, repos/
$ mkdir -p repos/repodata
$ cp -f patterns.xml comps.xml repos/repodata
$ createrepo -g repos/repodata/comps.xml repos/
$ modifyrepo repos/repodata/patterns.xml repos/repodata
</code>

Now, GPG sign your repos/repodata/repomd.xml file. Note that `modifyrepo` is a part of the `createrepo` package.

Build Infrastructure/Packagers Developers

2011-07-07T12:25:55Z

Kevinwang: /* How to use the commandline client */

These pages are in preparation - contributions welcome.

Note: See [[OBS|the OBS wiki page]] for explanation of the different OBS services MeeGo offers.

This track will give you a brief introduction to the features and capabilities of the OBS instance hosted at build.meego.com.
Note: You need an account to access build.meego.com.
If you have no account, you can still learn how the OBS works at the upstream project's own instance [http://build.opensuse.org http://build.opensuse.org] .

In this track, you'll learn how to use the web interface, the commandline client and create your first package.
The packaging guidelines and more advanced topics are also covered.

== How to get started ==

You need an account on build.meego.com. To request an account:
# Go to [http://bugs.meego.com MeeGo bugzilla].
# Click New in the upper navigational bar to begin filing a bug.
# On the next page, click MeeGo Community Infrastructure.
# On the following page, click Build Service and file your bug.

== How to use the web interface ==
A series of pages will make you familiar with webinterface basics. It's divided into several subpages:
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_1|Part 1 - Login and first steps]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_2|Part 2 - Creating a link and adding a repository]]
* [[Developing_in_a_MeeGo_Environment#Building_your_package:_Step_by_step|Part 3 - Your first own package]]

== How to use the commandline client ==
* Part 1 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_1|initial setup]]
* Part 2 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|checkout and branch]]
* Part 3 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_4|more commands: localcheckbuild]]

== MeeGo Packaging guidelines and Howto ==
* [[Packaging|Packaging]]
* [[Packaging/Guidelines|Packaging Guidelines]]
* [[SDK/Docs/1.0/Packaging/Tutorial|Packaging Tutorial]]

== [[Build_Infrastructure/QA|QA Processes around the OBS]] ==
See the [[Quality]] page.

== Verifying Your Package Changes Locally and Online ==
* [[Build_Infrastructure/Packagers_Developers/Using_OBS_chroot_for_development|Using OBS chroot for development]]

== Troubleshooting ==

* '''I'm getting "error: Package already exists: %package debuginfo"''' — Disable the debuginfo flag for the repo/arch that gives you this problem. You will probably still get a debuginfo package. This appears to happen when OBS creates debuginfo packages by default, and so this flag causes a sort of doubling-up of the debuginfo package.

== IRC / mailinglists / contact ==

If you need help, you can join #meego on irc.freenode.net . See also [[Community communication|this page]] about all MeeGo IRC channels.

You can join [http://lists.meego.com/listinfo/meego-dev MeeGo-dev] and [http://lists.meego.com/listinfo/meego-packaging MeeGo-packaging] mailing lists [http://lists.meego.com/mailman/listinfo over here].

[[Category:Build Infrastructure]]

Build Infrastructure

2011-07-07T12:13:32Z

Kevinwang: /* MeeGo Build Infrastructure */

== MeeGo Build Infrastructure ==

The heart of the Build Infrastructure of MeeGo is the upstream project [http://wiki.opensuse.org/Portal:Build_Service Open Build Service (OBS)]. It is an automated system used for building software packages, collaboration of developers, release management, maintenance, and much more. Moblin started using OBS in June 2008 and released Moblin 2.0 and Moblin 2.1, as well as other derivative releases. OBS has proven to be a very reliable, quickly evolving infrastructure. It is rich with distribution building and maintenance features. The Linux Foundation is dedicated to the further development of OBS and has a team, including two full-time OBS maintainers, contributing to its development and its use by MeeGo and the Ecosystem.

MeeGo currently uses OBS version 2.1.6. To learn more about version 2.1 and the additional features in it, see the upstream project details: [http://wiki.opensuse.org/openSUSE:Build_Service_Roadmap roadmap].

There are 2 build system instances that are relevant to MeeGo:
* MeeGo build system: Essentially, if you're a package maintainer/developer which is part of MeeGo, you get an account here.
* MeeGo public build system (AKA community OBS): For anyone to build applications or libraries against MeeGo. Anyone with a meego.com account can use this.

=== Overview - What does it do? ===
Let's set out some basics about the OBS.

# It's a build system. You put source on it and say "use this repository" and it builds a minimal SDK-like chroot using the deb/rpms it finds in that repository
# It has packages - a package corresponds to a tarball and a spec/dsc
# It has projects - a project is like a directory with packages
# When a package is built it is "published" from the project where it was uploaded into a corresponding repository (which can be used to build other projects)
# The repositories can also be used by devices to download binary packages.

[[File:Splash-community.png|right|300px]]
===MeeGo Build Service ===
The [http://build.meego.com MeeGo build system] is part of meego.com infrastructure and supports several important kinds of development:

* Applications to run on MeeGo
* Team Repositories
* Personal Repositories

Having these areas allow us to support:
* Managing packages as part of their acceptance into MeeGo core
* Deprecating packages from MeeGo core

=== MeeGo Community Build Service OBS ===
There's also a [[Build_Infrastructure/Community_Builder|MeeGo Build Service]] available.

=== [[Build_Infrastructure/Packagers_Developers|Packagers/Developers]] ===
* [[Build_Infrastructure/Packagers_Developers#How_to_get_started|How to get started.]]
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_webinterface|How to use the web interface to view, manage and build your packages.]]
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_commandline_client|How to use the command line client for daily operations]]
* [[Build_Infrastructure/Packagers_Developers#MeeGo_Packaging_guidelines_and_Howto|MeeGo Packaging guidelines and howto]]
* [[Build_Infrastructure/Packagers_Developers#QA_Processes_around_the_OBS|QA Processes around the OBS]]
* [[Build_Infrastructure/Packagers_Developers#Multi-Architecture_and_Multi-Distribution_packaging|Multi-Architecture and Multi-Distribution packaging]]
* [[Build_Infrastructure/Packagers_Developers#Tips_.26_Tricks|Verifying Your Package Changes Locally and Online]]
* [[Build_Infrastructure/Packagers_Developers#Troubleshooting|Troubleshooting]]
* [[Build_Infrastructure/Packagers_Developers#IRC_.2F_mailinglists_.2F_contact|irc / mailing lists / contact]]

[[File:peep_skate.png|right]]

=== [[Build_Infrastructure/Developing_OBS|Developing for the openSUSE Build Service]] ===
* [http://en.opensuse.org/openSUSE:Build_Service_private_instance How to set up a Build Service locally for testing]
* [[Build_Infrastructure/Sysadmin_Distro|More on setting up an OBS server]]
** [[Build_Infrastructure/Sysadmin_Distro#Seamless_cross-compilation.2C_cross-toolchain_integration|Seamless cross-compilation, cross-toolchain integration]]
* What's the [http://en.opensuse.org/openSUSE:Build_Service_Tutorial#Create_Patterns metadata (prjconf/prj), attributes, admin-tools for?]

[[File:peep_netbook.png|right]]

[[Category:Build Infrastructure]]

Distribution

2011-07-07T12:12:48Z

Kevinwang:

This page describes basic information you needed if you want to contribute to MeeGo. Target audience is community member who wish to involve in MeeGo development.

== Package Management and Development ==
=== Overview ===
[[File:Distribution-process-overview-with-obs.png|thumb|250px|right|The development process when using OBS]]
[[File:Distribution-process-without-obs.png|thumb|250px|right|The development process w/o using OBS]]
Like other Linux distros, MeeGo is a package-based system, and it is using [http://www.rpm.org/max-rpm/index.html RPM] package end. The RPM packages are managed in [http://wiki.meego.com/Zypper Zypper] repos. The MeeGo development is using [http://wiki.opensuse.org/Portal:Build_Service Open Build Service (OBS)] to manage and build packages. If you are a serious and frequent MeeGo contributor, you need an OBS account to commit your changes back to MeeGo. Casual contributors can work without using OBS, and submit your changes back into MeeGo through the [http://lists.meego.com/mailman/listinfo mailing list].

The overall processes of development with and without an OBS account are shown in the right figures. Detail description of the processes can be found below.

=== Development with MeeGo OBS account ===
* [[Build_Infrastructure/Packagers_Developers#How_to_get_started|Request a new OBS account]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_1|OBS WebUI: Login and first steps]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_2|OBS WebUI: Link packages and adding a repository]]
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_commandline_client|How to use the command line client for daily operations]]
* [[Build_Infrastructure/Packagers_Developers/Using_OBS_chroot_for_development|Using OBS chroot for development]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]
* [[Build_Infrastructure/Packagers_Developers#Troubleshooting|Troubleshooting]]

=== Development without MeeGo OBS account ===
* [[Local_Build_Without_OBS_Needed|Build and develop packages without OBS ]]
* [[Recompile_kernel | Example: Recompile kernel]]
* [[How to development with multiple packages with dependencies]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]

=== Packaging ===
* [[Packaging/Guidelines|Packaging Guidelines]]

=== Submission to MeeGo ===
* [[Release_Engineering/New_Package_Checklist|Checklist for new package submissions]]
* [[Release_Engineering/Submission_Checklist|Developer's checklist for code submissions]]
* [[Build_Infrastructure/Packagers_Developers#IRC_.2F_mailinglists_.2F_contact|irc / mailing lists / contact]]

== Software Repo ==
* [[Create and update repos]]
* [[Distribution/Package_Management|Package Management]]

== Developer Tools ==
=== Image Creation ===
* [[Image_Creation|MIC2]]
* [[Image_Creation_For_Beginners|MIC2 for Beginners]]
* [[Image Configurations - KickStart Files]]

=== OBS command line ===
* Part 1 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_1|initial setup]]
* Part 2 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|checkout & branch]]
* Part 3 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_4|more commands: localcheckbuild]]

=== Spec tool ===
* [[Spectacle|Spectacle]]

== Distribution Infrastructure ==
* [[Build_Infrastructure|Build Infrastructure - OBS]]
* [[Release_Infrastructure/BOSS|Release Infrastructure - BOSS]]

== Links ==
* [[Release_Engineering|Release Engineering]]
* [[Quality/Compliance|Compliance]]
* [[Quality|Quality]]

Distribution/Create image based on new RPM

2011-07-06T14:41:50Z

Kevinwang:

== Prepare your repo ==

=== Identify the live repo ===
If you build the package by using OBS, you can create the image based on the live repo. To get the live repo, please find the project on the OBS which contains the package you built first, for example: Projects->home:xxxx:branches:Trunk, click the build repository, such as "Trunk", then click "Go to download repository", you will get the link to the live repo: http://download.meego.com/live/home:/xxxx:/branches:/Trunk/Trunk/

=== Create local repo for your new RPMs ===
If you build the package in your local build environment(not on OBS), you can create a local repo and create the new image based on your local repo.
$cp *.rpm /var/tmp/localrepo/
$cd /var/tmp/localrepo/
$createrepo .

== Modify ks file to add the repo ==
Create your .ks file or get an existing ks file, for example meego-ivi-ia32-1.2.0.ks can be found at http://repo.meego.com/MeeGo/releases/1.2.0/images/meego-ivi-ia32/, for details about creating or updating ks file, please refer to: [[Image Configurations - KickStart Files]]

Once you get the ks file, what you need to do is adding the follow line to ks file:
$repo --name=live --baseurl=http://download.meego.com/live/home:/xxxx:/branches:/Trunk/Trunk/ --save
$repo --name=local --baseurl=file:///var/tmp/localrepo/ --save

== Run mic2 using the new ks file to generate image ==
More mic2 information can reference to [[Image_Creation|Image Creation]]

Here’s an example:
$/usr/bin/mic-image-creator --config=/root/mic/ivi-ia32.ks

Once mic-image-creator finished, you can find the new image from the output information.

Distribution

2011-07-06T14:10:11Z

Kevinwang: /* Development with MeeGo OBS account */

This page describes basic information you needed if you want to contribute to MeeGo. Target audience is community member who wish to involve in MeeGo development.

== Package Management and Development ==
=== Overview ===
Like other Linux distros, MeeGo is a package-based system, and it is using [http://www.rpm.org/max-rpm/index.html RPM] package end. The RPM packages are managed in [http://wiki.meego.com/Zypper Zypper] repos. The MeeGo development is done by using the upstream project [http://wiki.opensuse.org/Portal:Build_Service Open Build Service (OBS)]. If you are a serious and frequent MeeGo contributor, you need an OBS account to commit your changes back to MeeGo. Other casual contributors can work without using OBS, but you need a MeeGo development team member to help review and commit your changes into MeeGo.

The process of develop with an OBS account:
Branch, Check-out, Make changes, Deployment the new package and test, Make a new image (optional), Submit your changes.

The process of develop without using OBS:
Download MeeGo from a repo, build a chroot env, get the source of a package, make changes, build and test the new package, how to debug the local build, find a MeeGo team member to sponsor your changes and submit them back.

=== Development with MeeGo OBS account ===
* [[Build_Infrastructure/Packagers_Developers#How_to_get_started|Request a new OBS account]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_1|OBS WebUI: Login and first steps]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_2|OBS WebUI: Link packages and adding a repository]]
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_commandline_client|How to use the command line client for daily operations]]
* [[Build_Infrastructure/Packagers_Developers/Using_OBS_chroot_for_development|Using OBS chroot for development]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]
* [[Build_Infrastructure/Packagers_Developers#Troubleshooting|Troubleshooting]]

=== Development without MeeGo OBS account ===
* [[Local_Build_Without_OBS_Needed|Build and develop packages without OBS ]]
* [[Recompile_kernel | Example: Recompile kernel]]
* [[How to development with multiple packages with dependencies]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]

=== Packaging ===
* [[Packaging/Guidelines|Packaging Guidelines]]

=== Submission to MeeGo ===
* [[Release_Engineering/New_Package_Checklist|Checklist for new package submissions]]
* [[Release_Engineering/Submission_Checklist|Developer's checklist for code submissions]]
* [[Build_Infrastructure/Packagers_Developers#IRC_.2F_mailinglists_.2F_contact|irc / mailing lists / contact]]

== Developer Tools ==
=== Image Creation ===
* [[Image_Creation|MIC2]]
* [[Image_Creation_For_Beginners|MIC2 for Beginners]]
* [[Image Configurations - KickStart Files]]

=== OBS command line ===
* Part 1 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_1|initial setup]]
* Part 2 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|checkout & branch]]
* Part 3 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_4|more commands: localcheckbuild]]

=== Spec tool ===
* [[Spectacle|Spectacle]]

== Software Repo ==
* [[Create and update repos]]
* [[Distribution/Package_Management|Package Management]]

== Distribution Infrastructure ==
* [[Build_Infrastructure|Build Infrastructure - OBS]]
* [[Release_Infrastructure/BOSS|Release Infrastructure - BOSS]]

== Links ==
* [[Release_Engineering|Release Engineering]]
* [[Quality/Compliance|Compliance]]
* [[Quality|Quality]]

Distribution/Create image based on new RPM

2011-07-06T14:03:57Z

Kevinwang: /* Create new image based on new RPM */

You can create a new image based on your local repo

Steps as follows:
* Environment setup
install the package "createrepo"

* Create local repo for your new RPMs
$cp *.rpm /var/tmp/localrepo/
$cd /var/tmp/localrepo/
$createrepo .

* Modify ks file to add local repo
Create your .ks file or get an existing ks file, for example meego-ivi-ia32-1.2.0.ks can be found http://repo.meego.com/MeeGo/releases/1.2.0/images/meego-ivi-ia32/, for details about creating or updating ks file, please refer to: [[Image Configurations - KickStart Files]]

Once you get the ks file, what you need to do is adding the follow line to ks file:
$repo --name=local --baseurl=file:///var/tmp/localrepo/ --save

*Run mic2 using the new ks file to generate image
More mic2 information can reference to [[Image_Creation|Image Creation]]

Here’s an example:
$/usr/bin/mic-image-creator --config=/root/mic/ivi-ia32.ks

Once mic-image-creator finished, you can find the new image from the output information.

*Using the new image to install or boot up on device.

Distribution

2011-07-06T13:49:15Z

Kevinwang: /* submission to MeeGo */

This page describes basic information you needed if you want to contribute to MeeGo. Target audience is community member who wish to involve in MeeGo development.

== Package Management and Development ==
=== Overview ===
Like other Linux distros, MeeGo is a package-based system, and it is using [http://www.rpm.org/max-rpm/index.html RPM] package end. The RPM packages are managed in [http://wiki.meego.com/Zypper Zypper] repos. The MeeGo development is done by using the upstream project [http://wiki.opensuse.org/Portal:Build_Service Open Build Service (OBS)]. If you are a serious and frequent MeeGo contributor, you need an OBS account to commit your changes back to MeeGo. Other casual contributors can work without using OBS, but you need a MeeGo development team member to help review and commit your changes into MeeGo.

The process of develop with an OBS account:
Branch, Check-out, Make changes, Deployment the new package and test, Make a new image (optional), Submit your changes.

The process of develop without using OBS:
Download MeeGo from a repo, build a chroot env, get the source of a package, make changes, build and test the new package, how to debug the local build, find a MeeGo team member to sponsor your changes and submit them back.

=== Development with MeeGo OBS account ===
* [[Build_Infrastructure/Packagers_Developers#How_to_get_started|Request a new OBS account]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_1|Login and first steps]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_2|Link packages and adding a repository]]
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_commandline_client|How to use the command line client for daily operations]]
* [[Build_Infrastructure/Packagers_Developers/Using_OBS_chroot_for_development|Using OBS chroot for development]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]
* [[Build_Infrastructure/Packagers_Developers#Troubleshooting|Troubleshooting]]

=== Development without MeeGo OBS account ===
* [[Local_Build_Without_OBS_Needed|Build and develop packages without OBS ]]
* [[Recompile_kernel | Example: Recompile kernel]]
* [[How to development with multiple packages with dependencies]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]

=== Packaging ===
* [[Packaging/Guidelines|Packaging Guidelines]]

=== Submission to MeeGo ===
* [[Release_Engineering/New_Package_Checklist|Checklist for new package submissions]]
* [[Release_Engineering/Submission_Checklist|Developer's checklist for code submissions]]
* [[Build_Infrastructure/Packagers_Developers#IRC_.2F_mailinglists_.2F_contact|irc / mailing lists / contact]]

== Developer Tools ==
=== Image Creation ===
* [[Image_Creation|MIC2]]
* [[Image_Creation_For_Beginners|MIC2 for Beginners]]
* [[Image Configurations - KickStart Files]]

=== OBS command line ===
* Part 1 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_1|initial setup]]
* Part 2 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|checkout & branch]]
* Part 3 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_4|more commands: localcheckbuild]]

=== Spec tool ===
* [[Spectacle|Spectacle]]

== Software Repo ==
* [[Create and update repos]]
* [[Distribution/Package_Management|Package Management]]

== Distribution Infrastructure ==
* [[Build_Infrastructure|Build Infrastructure - OBS]]
* [[Release_Infrastructure/BOSS|Release Infrastructure - BOSS]]

== Links ==
* [[Release_Engineering|Release Engineering]]
* [[Quality/Compliance|Compliance]]
* [[Quality|Quality]]

Distribution

2011-07-06T13:48:48Z

Kevinwang: /* Process */

This page describes basic information you needed if you want to contribute to MeeGo. Target audience is community member who wish to involve in MeeGo development.

== Package Management and Development ==
=== Overview ===
Like other Linux distros, MeeGo is a package-based system, and it is using [http://www.rpm.org/max-rpm/index.html RPM] package end. The RPM packages are managed in [http://wiki.meego.com/Zypper Zypper] repos. The MeeGo development is done by using the upstream project [http://wiki.opensuse.org/Portal:Build_Service Open Build Service (OBS)]. If you are a serious and frequent MeeGo contributor, you need an OBS account to commit your changes back to MeeGo. Other casual contributors can work without using OBS, but you need a MeeGo development team member to help review and commit your changes into MeeGo.

The process of develop with an OBS account:
Branch, Check-out, Make changes, Deployment the new package and test, Make a new image (optional), Submit your changes.

The process of develop without using OBS:
Download MeeGo from a repo, build a chroot env, get the source of a package, make changes, build and test the new package, how to debug the local build, find a MeeGo team member to sponsor your changes and submit them back.

=== Development with MeeGo OBS account ===
* [[Build_Infrastructure/Packagers_Developers#How_to_get_started|Request a new OBS account]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_1|Login and first steps]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_2|Link packages and adding a repository]]
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_commandline_client|How to use the command line client for daily operations]]
* [[Build_Infrastructure/Packagers_Developers/Using_OBS_chroot_for_development|Using OBS chroot for development]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]
* [[Build_Infrastructure/Packagers_Developers#Troubleshooting|Troubleshooting]]

=== Development without MeeGo OBS account ===
* [[Local_Build_Without_OBS_Needed|Build and develop packages without OBS ]]
* [[Recompile_kernel | Example: Recompile kernel]]
* [[How to development with multiple packages with dependencies]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]

=== Packaging ===
* [[Packaging/Guidelines|Packaging Guidelines]]

=== submission to MeeGo ===
* [[Release_Engineering/New_Package_Checklist|Checklist for new package submissions]]
* [[Release_Engineering/Submission_Checklist|Developer's checklist for code submissions]]
* [[Build_Infrastructure/Packagers_Developers#IRC_.2F_mailinglists_.2F_contact|irc / mailing lists / contact]]

== Developer Tools ==
=== Image Creation ===
* [[Image_Creation|MIC2]]
* [[Image_Creation_For_Beginners|MIC2 for Beginners]]
* [[Image Configurations - KickStart Files]]

=== OBS command line ===
* Part 1 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_1|initial setup]]
* Part 2 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|checkout & branch]]
* Part 3 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_4|more commands: localcheckbuild]]

=== Spec tool ===
* [[Spectacle|Spectacle]]

== Software Repo ==
* [[Create and update repos]]
* [[Distribution/Package_Management|Package Management]]

== Distribution Infrastructure ==
* [[Build_Infrastructure|Build Infrastructure - OBS]]
* [[Release_Infrastructure/BOSS|Release Infrastructure - BOSS]]

== Links ==
* [[Release_Engineering|Release Engineering]]
* [[Quality/Compliance|Compliance]]
* [[Quality|Quality]]

Distribution

2011-07-06T13:47:10Z

Kevinwang:

This page describes basic information you needed if you want to contribute to MeeGo. Target audience is community member who wish to involve in MeeGo development.

== Package Management and Development ==
=== Overview ===
Like other Linux distros, MeeGo is a package-based system, and it is using [http://www.rpm.org/max-rpm/index.html RPM] package end. The RPM packages are managed in [http://wiki.meego.com/Zypper Zypper] repos. The MeeGo development is done by using the upstream project [http://wiki.opensuse.org/Portal:Build_Service Open Build Service (OBS)]. If you are a serious and frequent MeeGo contributor, you need an OBS account to commit your changes back to MeeGo. Other casual contributors can work without using OBS, but you need a MeeGo development team member to help review and commit your changes into MeeGo.

The process of develop with an OBS account:
Branch, Check-out, Make changes, Deployment the new package and test, Make a new image (optional), Submit your changes.

The process of develop without using OBS:
Download MeeGo from a repo, build a chroot env, get the source of a package, make changes, build and test the new package, how to debug the local build, find a MeeGo team member to sponsor your changes and submit them back.

=== Development with MeeGo OBS account ===
* [[Build_Infrastructure/Packagers_Developers#How_to_get_started|Request a new OBS account]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_1|Login and first steps]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_2|Link packages and adding a repository]]
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_commandline_client|How to use the command line client for daily operations]]
* [[Build_Infrastructure/Packagers_Developers/Using_OBS_chroot_for_development|Using OBS chroot for development]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]
* [[Build_Infrastructure/Packagers_Developers#Troubleshooting|Troubleshooting]]

=== Development without MeeGo OBS account ===
* [[Local_Build_Without_OBS_Needed|Build and develop packages without OBS ]]
* [[Recompile_kernel | Example: Recompile kernel]]
* [[How to development with multiple packages with dependencies]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]

=== Packaging ===
* [[Packaging/Guidelines|Packaging Guidelines]]

=== Process ===
* [[Release_Engineering/New_Package_Checklist|Checklist for new package submissions]]
* [[Release_Engineering/Submission_Checklist|Developer's checklist for code submissions]]
* [[Build_Infrastructure/Packagers_Developers#IRC_.2F_mailinglists_.2F_contact|irc / mailing lists / contact]]

== Developer Tools ==
=== Image Creation ===
* [[Image_Creation|MIC2]]
* [[Image_Creation_For_Beginners|MIC2 for Beginners]]
* [[Image Configurations - KickStart Files]]

=== OBS command line ===
* Part 1 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_1|initial setup]]
* Part 2 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|checkout & branch]]
* Part 3 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_4|more commands: localcheckbuild]]

=== Spec tool ===
* [[Spectacle|Spectacle]]

== Software Repo ==
* [[Create and update repos]]
* [[Distribution/Package_Management|Package Management]]

== Distribution Infrastructure ==
* [[Build_Infrastructure|Build Infrastructure - OBS]]
* [[Release_Infrastructure/BOSS|Release Infrastructure - BOSS]]

== Links ==
* [[Release_Engineering|Release Engineering]]
* [[Quality/Compliance|Compliance]]
* [[Quality|Quality]]

Distribution

2011-07-06T13:46:24Z

Kevinwang: /* Overview */

This page describes basic information you needed if you want to contribute to MeeGo. Target audience is community member who wish to involve in MeeGo development.

== Package Management and Development ==
=== Overview ===
Like other Linux distros, MeeGo is a package-based system, and it is using [http://www.rpm.org/max-rpm/index.html RPM] package end. The RPM packages are managed in [http://wiki.meego.com/Zypper Zypper] repos. The MeeGo development is done by using the upstream project [http://wiki.opensuse.org/Portal:Build_Service Open Build Service (OBS)]. If you are a serious and frequent MeeGo contributor, you need an OBS account to commit your changes back to MeeGo. Other casual contributors can work without using OBS, but you need a MeeGo development team member to help review and commit your changes into MeeGo.

The process of develop with an OBS account:
Branch, Check-out, Make changes, Deployment the new package and test, Make a new image (optional), Submit your changes.

The process of develop without using OBS:
Download MeeGo from a repo, build a chroot env, get the source of a package, make changes, build and test the new package, how to debug the local build, find a MeeGo team member to sponsor your changes and submit them back.

=== Development with MeeGo OBS account ===
* [[Build_Infrastructure/Packagers_Developers#How_to_get_started|Request a new OBS account]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_1|Login and first steps]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_2|Link packages and adding a repository]]
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_commandline_client|How to use the command line client for daily operations]]
* [[Build_Infrastructure/Packagers_Developers/Using_OBS_chroot_for_development|Using OBS chroot for development]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]
* [[Build_Infrastructure/Packagers_Developers#Troubleshooting|Troubleshooting]]

=== Development without MeeGo OBS account ===
* [[Local_Build_Without_OBS_Needed|Build and develop packages without OBS ]]
* [[Recompile_kernel | Example: Recompile kernel]]
* [[How to development with multiple packages with dependencies]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]

=== Packaging ===
* [[Packaging/Guidelines|Packaging Guidelines]]

=== Process ===
* [[Release_Engineering/New_Package_Checklist|Checklist for new package submissions]]
* [[Release_Engineering/Submission_Checklist|Developer's checklist for code submissions]]
* [[Build_Infrastructure/Packagers_Developers#IRC_.2F_mailinglists_.2F_contact|irc / mailing lists / contact]]

== Developer Tools ==
=== Image Creation ===
* [[Image_Creation|MIC2]]
* [[Image_Creation_For_Beginners|MIC2 for Beginners]]
* [[Image Configurations - KickStart Files]]

=== OBS command line ===
* Part 1 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_1|initial setup]]
* Part 2 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|checkout & branch]]
* Part 3 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_4|more commands: localcheckbuild]]

=== Spec tool ===
* [[Spectacle|Spectacle]]

== Distribution Infrastructure ==
* [[Build_Infrastructure|Build Infrastructure - OBS]]
* [[Release_Infrastructure/BOSS|Release Infrastructure - BOSS]]

== Software Repo ==
* [[Create and update repos]]

== Links ==
* [[Release_Engineering|Release Engineering]]
* [[Quality/Compliance|Compliance]]
* [[Quality|Quality]]

Image Creation

2011-07-06T13:43:11Z

Kevinwang: /* KickStart Files (configuration files used for image creation) */

= Overview =

This is the main Image Creator developer's guide. For a more simplistic, step-by-step document, go to: [[Image Creation For Beginners]].

The tool used to create MeeGo images is called "MIC2" (to distinguish from obsolete MIC - Moblin Image Creator). MIC is composed of a series of tools to create images, convert images, and do some development work on MeeGo. MIC2 is based primarily on Fedora livecd-tools and appliance-tools.

With MIC2 tools, users can create different types of images for different purposes, including live CD images, live USB images, raw images for KVM, VMDK images for Vmware, vdi images for VirtualBox, loop images for IVI platforms, NAND images for Moorestown platforms, ubi images for N900, fs image for MeeGo developers. Also, users can use MIC2 tools to manipulate images, like transforming an image from a virtual machine to a live image, and providing a chroot environment based on an existing live image. With these features, developers can do development work on a host virtual machine running MeeGo or a Meego chroot environment, and transfer the resulting new live image to a target device for final debug/verification.

This document discusses only features, usage guide, and known issues.

= Features =

MIC2 offers these major tools:
* mic-image-creator: create images.
* mic-image-convertor: convert a raw/vmdk/vdi/live image into a live image.
* mic-chroot: provide a MeeGo environment from a live/loop image for development, it also can translate that chroot file system into a live image.
* mic-image-writer: write a MeeGo image to a USB disk. This is a safe alternative to dd.

The following support is provided:

* Supports mainstream Linux distros. MIC2 has been thoroughly tested on these distributions:
** Meego
** Fedora (Fedora 13 and above)
** Opensuse (> OpenSUSE 11.3)
** and Ubuntu > 10.04
* Supports various types of images: livecd, liveusb, loop, raw, vmdk, nandmrst, vdi, fs, ubi
* Supports image coversion from virtual machine/live images to live images.
* Uses kickstart (.ks) files for image creation. Through this, users can specify which software repositories to use, which packages to install, and basic system configuration directives. Please refer to http://fedoraproject.org/wiki/Anaconda/Kickstart for more information about kickstart configuration files.

= Usage =

== Requirements ==

To use MIC2, your host machine (that will run mic2) must have Intel* Atom* or Intel* Core* 2 CPU (support for SSSE3), this is a hard requirement (ARM image is exceptional).

On Fedora, openSUSE and MeeGo, mic2 depends directly on the following packages (they will be automatically installed on installing mic2):

* util-linux
* coreutils
* python >= 2.5
* e2fsprogs
* dosfstools >= 2.11-8
* yum >= 3.2.24
* pykickstart >= 0.96
* python-iniparse
* syslinux >= 3.82
* curl
* kpartx
* parted
* device-mapper
* zlib
* rsync
* /usr/bin/mkisofs
* wget
* cpio
* isomd5sum
* gzip
* bzip2
* squashfs-tools >= 4.0
* btrfs-progs
* python-zypp >= 0.5.7

On Debian and Ubuntu, mic2 depends on or recommands or suggests the following packages (they will be automatically installed if possible on installing mic2):

Depends:

* bzip2
* curl
* dbus
* dmsetup
* dosfstools
* e2fsprogs (>= 1.41),
* genisoimage
* kpartx
* parted
* psmisc
* python-iniparse
* python-pykickstart (>= 0.96) | pykickstart (>= 0.96),
* python-urlgrabber
* rsync
* squashfs-tools (>= 4.0)
* syslinux (>= 3.82)
* yum (>= 3.2)

Recommends:

* binfmt-support
* btrfs-tools
* extlinux
* qemu-user-static
* udisks | hal

Suggests:

* python-zypp

For source installation, these two packages are necessary:

* zlib-devel(for compiling)
* python-devel(for installation)

You should load these modules, as well, if they're not loaded automatically by the kernel:
 (Use <code>lsmod</code> to list modules.)

* squashfs
* squashfs-tools
* dm_snapshot
* loop

Specific packages for Ubuntu 8.10:

* python-celementtree
* python-elementtree
* dmsetup

=== Installing requirements for Ubuntu 10.10 ===

sudo apt-get install yum rpm kpartx parted syslinux isomd5sum kvm zlib1g-dev squashfs-tools python2.6-dev qemu-arm-static python-urlgrabber

== Installation ==

We currently build MIC2 binary rpms/debs for many popular Linux distributions, including Fedora 13, Fedora 14, Fedora15, Ubuntu 10.04, Ubuntu 10.10, OpenSUSE 11.3, OpenSUSE 11.4, and Debian 5.0. Please go to http://repo.meego.com/tools/repos/ to get a repository URL corresponding to your Linux distribution, then add it into your repo or package source for installation and update later. If your distribution isn't in the support list, please install MIC2 from git source.

=== Binary Package installation ===

* '''Installation Steps For Fedora 13, Fedora 14, and Fedora 15'''

1. Add MIC2 repo as user root:

<pre>
# cat <<REPO > /etc/yum.repos.d/meego-tools.repo
[meego-tools]
name=MeeGo Tools for Fedora
baseurl=http://repo.meego.com/MeeGo/tools/repos/fedora/\$releasever
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-meego
REPO
</pre>

2. Add gpg key as user root:

<pre>
# gpg2 --keyserver subkeys.pgp.net --recv 0BC7BEC479FC1F8A
# gpg2 --export --armor 0BC7BEC479FC1F8A > /etc/pki/rpm-gpg/RPM-GPG-KEY-meego
</pre>

3. Install mic2 as user root:
<pre>
# yum install mic2
</pre>

if you get asked to import the key do so:
<pre>
warning: rpmts_HdrFromFdno: Header V3 DSA/SHA1 Signature, key ID 79fc1f8a: NOKEY
meego-fedora/gpgkey | 3.3 kB 00:00 ...
Importing GPG key 0x79FC1F8A:
Userid: "Moblin Build (Moblin Build User) <build@moblin.org>"
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-meego
Is this ok [y/N]: y
</pre>

* '''Update Steps For Fedora 13, Fedora 14, and Fedora 15'''

You can use the below command to get the latest mic2 package.

<pre>
# yum update mic2
</pre>

* '''Installation Steps For Ubuntu 10.04, Ubuntu 10.10, and Debian 5.0'''

1. Add package source

For Ubuntu 10.04, add the below line to /etc/apt/sources.list

<pre>
deb http://repo.meego.com/MeeGo/tools/repos/ubuntu/10.04/ /
</pre>

For Ubuntu 10.10, add the below line to /etc/apt/sources.list

<pre>
deb http://repo.meego.com/MeeGo/tools/repos/ubuntu/10.10/ /
</pre>

For Debian 5.0, add the below line to /etc/apt/sources.list

<pre>
deb http://repo.meego.com/MeeGo/tools/repos/debian/5.0/ /
</pre>

mic2 is also available in Debian Testing, which will become Debian 6.0.

2. sudo apt-get update

You should see the following error:
W: GPG error: http://repo.meego.com Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0BC7BEC479FC1F8A

To add the repository public key use the following command:
:gpg --keyserver subkeys.pgp.net --recv 0BC7BEC479FC1F8A
:gpg --export --armor 0BC7BEC479FC1F8A | sudo apt-key add -

Note: Often the port used by gpg is blocked in companies, so gpg will time out. You can install it manually; this example is for Ubuntu 10.10:
:wget http://repo.meego.com/MeeGo/tools/repos/ubuntu/10.10/Release.key
Open System->Administrator->Software Sources. Under the Authentication tab, import the key.

Now redo sudo apt-get update

3. sudo apt-get install mic2

* '''Installation Steps For OpenSUSE 11.3, and OpenSUSE 11.4'''

1. Add repos

For OpenSUSE 11.3:

<pre>sudo zypper addrepo http://repo.meego.com/MeeGo/tools/repos/opensuse/11.3/ meego-tools</pre>

For OpenSUSE 11.4:

<pre>sudo zypper addrepo http://repo.meego.com/MeeGo/tools/repos/opensuse/11.4/ meego-tools</pre>

2. sudo zypper install mic2

* '''Install Steps For OpenSUSE 11.3, and OpenSUSE 11.4'''

<pre>
sudo zypper install mic2
</pre>

=== From Stable Git Source Releases ===

You can get the latest stable release of MIC2 from the tag section in http://meego.gitorious.org/meego-developer-tools/image-creator. Click on the "Source tree" link on the top of the screen. There will be a list of tags on the right hand side.

You should follow the below steps to install it:

<pre>
git clone git://gitorious.org/meego-developer-tools/image-creator.git
cd image-creator
git checkout 0.17 #check Gitorious for the most recent tag
make
sudo make install
</pre>

=== From Development Git Tree ===

Note: MIC2 GIT tree has latest-and-greatest source, so stability is not guaranteed. If you run into errors, please use a 'Stable Release' instead before filing a bug.

You need to follow the below steps to git clone MIC2:

<pre>
git clone git://gitorious.org/meego-developer-tools/image-creator.git
</pre>

Build and install:

<pre>
cd image-creator
make clean
make
sudo make install
</pre>

You should add the repo for mic2 then run

<pre>
sudo ./tools/mic-check-alldeps
</pre>

to check/install all the depended packages, otherwise mic2 can't work normally.

== Proxy Setting ==

If you need to use proxy to access Internet, you must set proxy for mic2 correctly. Generally, you should export these environment variables:

<pre>
$ export http_proxy="http://proxy.yourcompany.com:8888"
$ export https_proxy="http://proxy.yourcompany.com:8888"
$ export no_proxy="127.0.0.0/8, .yourcompany.com"
</pre>

If you use sudo to run mic2, you also need to add these into /etc/sudoers in order that they still are valid after sudo.

<pre>
$ sudo visudo

Add: Defaults env_keep += " no_proxy http_proxy https_proxy"
</pre>

so sudo will adhere to the no_proxy and proxy settings.

You also can set proxy in /etc/mic2/mic2.conf or in ~/.mic2.conf by adding the below two lines:

<pre>
proxy=http://proxy.yourcompany.com:8888/
no_proxy=localhost,127.0.0.0/8,.yourcompany.com
</pre>

Of course, you need to change proxy.yourcompany.com:8888 and .yourcompany.com according to your network.

From mic2 0.23.0 on, mic2 enabled zypp backend, it uses /etc/sysconfig/proxy to get proxy settings, so you also need to create this file (it is a system file in OpenSUSE, so for openSUSE, you just set correct values inside of it) if you need to use proxy to access internet. Here is a sample:

<pre>
#### /etc/sysconfig/proxy sample ####
## Path: Network/Proxy
## Description:
## Type: yesno
## Default: no
## Config: kde,profiles
#
# Enable a generation of the proxy settings to the profile.
# This setting allows to turn the proxy on and off while
# preserving the particular proxy setup.
#
PROXY_ENABLED="yes"

## Type: string
## Default: ""
#
# Some programs (e.g. lynx, arena and wget) support proxies, if set in
# the environment. SuSEconfig can add these environment variables to
# /etc/SuSEconfig/* (sourced by /etc/profile etc.) -
# See http://portal.suse.com/sdb/en/1998/01/lynx_proxy.html for more details.
# Example: HTTP_PROXY="http://proxy.provider.de:3128/"
HTTP_PROXY="http://proxy.yourcompany.com:8888/"

## Type: string
## Default: ""
#
# Some programs (e.g. lynx, arena and wget) support proxies, if set in
# the environment. SuSEconfig can add these environment variables to
# /etc/SuSEconfig/* (sourced by /etc/profile etc.) -
# this setting is for https connections
HTTPS_PROXY="http://proxy.yourcompany.com:8888/"

## Type: string
## Default: ""
#
# Example: FTP_PROXY="http://proxy.provider.de:3128/"
#
FTP_PROXY="http://proxy.yourcompany.com:8888/"

## Type: string
## Default: ""
#
# Example: GOPHER_PROXY="http://proxy.provider.de:3128/"
#
GOPHER_PROXY=""

## Type: string(localhost)
## Default: localhost
#
# Example: NO_PROXY="www.me.de, do.main, localhost"
#
NO_PROXY="localhost, 127.0.0.1, .yourcompany.com"

#### /etc/sysconfig/proxy sample ####
</pre>

You need to change proxy.yourcompany.com:8888 and .yourcompany.com according to your network. By default, zypp will be used, but you can use option --pkgmgr=yum to force mic2 to use yum, you can do so if you find zypp can't work for you, but remember to file a bug on http://bugs.meego.com/enter_bug.cgi?product=Development%20Tools&component=MIC%20(Image%20Creator) if you find any issue related to zypp.

An option --proxy for repo command in kickstart file also can set proxy, you can specify it as follows:

<pre>
repo --name=meego --baseurl=http://repo.meego.com/trunk/repo/ia32/os/ --proxy=http://proxyhost:proxyport/
</pre>

You also need to add two more options to repo if your proxy needs user authentication:

<pre>
repo --name=meego --baseurl=http://repo.meego.com/trunk/repo/ia32/os/ --proxy=http://proxyhost:proxyport/ --proxyuser=proxyusername --proxypaswd=proxyuserpassword
</pre>

== Running mic-image-creator ==

Configuration of images is based on kickstart, the format used for unattended installation in Fedora and Redhat.

Super user privileges are needed. The tool is more or less self-documented, use the --help option to see options.
<pre>
sudo mic-image-creator --help
</pre>

=== Creating Supported Image Types ===

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

creating arm images needs 'qemu-arm' os 'qemu-arm-static' command available, and creating vdi or vmdk images needs 'vboxmanager' available, so be sure your system have installed them before creating these types of images.

To obtain the official Meego .ks files, go here: http://wiki.meego.com/Image_Creation#Official_Meego_.ks_files

'''Create ARMv7 Images'''

When creating images for ARMv7 hardware, pass ''--arch=armv7hl'' to ''mic-image-creator'' commands.

'''Create Livecd Image'''

<pre>
sudo mic-image-creator --config=default.ks --format=livecd --cache=mycache
</pre>

This tells image-creator to use the kickstart file default.ks to obtain info about which packages to download and include in the image, and --cache is the directory on your local machine which will host a cache of these packages. The cache is very useful if you are remote to the server and reduces the amount of downloaded packages next time you create an image. Next time the command is run, this cache will simply be 'updated' if there are changes, rather than re-downloading from the repositories again.

The output of this command will be a file named meego-1.2-default-XX.iso created. This ISO image is a hybrid image and can be either written to a disk device or burned onto a cd.

To burn it onto a USB stick, just run the following command, assuming the USB stick is /dev/sdb in your system:

<pre>
sudo mic-image-writer meego-1.2-default-XX.iso
</pre>

'''Create Moorestown NAND Image'''

<pre>
sudo mic-image-creator --config=default.ks --format=mrstnand

remove the first 512 bytes from the image to remove the partition information.
sudo dd bs=512 skip=1 if=meego-1.2-default-XX-sda.bin of= meego-1.2-default-XX-nand.img
</pre>

'''Create Liveusb Image'''

<pre>
sudo mic-image-creator --config=default.ks --format=liveusb --cache=mycache
</pre>

A file named meego-1.0-default-XX.usbimg will be created. To burn it onto a USB stick, run the following command, assuming the USB stick is /dev/sdb in your system:

<pre>
sudo mic-image-writer meego-1.2-default-XX.usbimg
</pre>

This image has a FAT file system and can be mounted easily on Windows and other OSes.

'''Create Liveusb Image Interactively'''

<pre>
sudo mic-image-creator --config=default.ks --format=liveusb --interactive --cache=mycache
</pre>

It directly creates a MeeGo live usb stick.

Liveusb image can be created in two different ways, interactive and non-interactive (default). When running MIC2 in a non-interactive mode, MIC2 creates a USB images file that can be copied directly into a USB stick. The non-interactive mode can be used for daily build or automated testing. The interactive mode will write the images onto a USB disk, it will detect if a USB stick is available and detects and verifies a partition is available. If two or more USB devices are present, you will be asked to select the target device. This way the contents of the existing USB stick won't be destroyed unless no appropriate partition is found, end user should use it to create the live USB.

'''Create Loop Image'''

This is the simplest image format available. Such images can be loop mounted and chrooted into, for example, to build applications or for debugging purposes.

<pre>
sudo mic-image-creator --config=default.ks --format=loop --cache=mycache
</pre>

A file named meego-1.2-default-XX.img is created. You can use below to mount it and chroot into it.

<pre>
sudo mount -o loop meego-1.2-default-XX.img /mnt
sudo chroot /mnt su -
</pre>

'''Create KVM Image'''

Can be used with QEMU or other VMM applications to launch MeeGo as a virtualized instance.

<pre>
sudo mic-image-creator --config=default.ks --format=raw --cache=mycache
</pre>

A file named meego-1.2-default-XX folder with a meego-1.2-default-XX-sda.raw image is created. For optimal results, use this feature in a machine with VT support and enable it in the BIOS.

If you use Fedora or openSUSE, run the following command to launch the image into MeeGo KVM virtual machine:

<pre>
sudo qemu-kvm -m 512 -boot c -hda meego-1.2-default-XX-sda.raw -std-vga
</pre>

If you use Ubuntu, run the following command launch image:

<pre>
sudo kvm -m 512 -boot c -hda meego-1.2-default-XX-sda.raw
</pre>

'''Create VMDK Image'''

VMDK images can be loaded into Vmware or Vmware player. MIC2 also generates a VMX file that has image configuration and can be used to launch the image in Vmware by just clicking the file. If you have vmplayer, it should open automatically.

<pre>
sudo mic-image-creator --config=default.ks --format=vmdk --cache=mycache
</pre>

A file named meego-1.2-default-XX folder with both meego-1.2-default-XX-sda.vmdk image and meego-1.2-default-XX-sda.vmx is created. Just run vmware or vmware player, and select the generated vmx file.

=== KickStart Files (configuration files used for image creation) ===

* [[Image Configurations - KickStart Files]]

=== MIC2 Configuration file ===

MIC2 options can be specified in a global configuration file ('''/etc/mic2/mic2.conf''') and local configuration file ('''$HOME/.mic2.conf'''), where you can specify:
* Repository configuration
* proxy settings
* cache directories and
* other variables
that you normally would have to re-type in your command-line.

The two configuration files have the same format, /etc/mic2/mic2.conf is global, no matter whoever is running MIC2, this configuration file will be read first, $HOME/.mic2.conf is just valid for current user, every user can have their own settings.
The final configuration is a combination of two configuration files, options in '''$HOME/.mic2.conf''' will override those from '''/etc/mic2/mic2.conf'''. Options from command line have the highest priority.
If an option is specified on the command line, the same option in both configuration files, global and local will be ignored.

Below is an example you can cut-and-paste, and reuse for your needs:

<pre>
[main]
cachedir=/home/user1/mycache
tmpdir=/home/user1/mystorage/tmp
outdir=/home/user1/mystorage
proxy=http://my.proxy.com:911/
no_proxy=localhost,127.0.0.0/8,.mysite.com,172.16.0.0/16
</pre>

''cachedir'' = directory where the cached repo(s) will reside. With this variable set, you do not need to pass the --cache flag in the command-line.

''tmpdir'' = temporary directory used by MIC2 when creating images. With this variable set, you do not need to pass the --tmpdir flag in the command-line.

''outdir'' = where your images will reside once they are created. With this variable set, you do not need to pass the --outdir flag in the command-line.

''proxy'' = specify your proxy if you're behind a behind a firewall.

''no_proxy'' = specify what domains should not sure the proxy setting.

''image_format'' = specify image format.

''default_ks'' = specify a default kickstart file, there are several kickstart files provided in repository http://repo.meego.com/MeeGo/devel/trunk/repo/ia32/os/

'''Note:''' When specifying proxy and no_proxy, you do not need to use the --proxy flag in your .ks files when referring to repos.

In configuration files, you also can specify one or multiple repositories, for example:

<pre>
[trunk]
name=trunk
baseurl=http://repo.meego.com/MeeGo/devel/trunk/repo/ia32/os/
enabled=1
</pre>

Once there is this repository info in your configuration files, and both image_format and default_ks are set, you can just run "sudo mic-image-creator" to create a image, there isn't any extra argument needed.

=== Use Bootstrap ===

MIC2 highly depends on yum and librpm, but different Linux distributions used diffrent yum and librpm versions, so MIC2 has some compatibility issues on OpenSUSE, Ubuntu and Debian, bootstrap is just for fixing these compatibility issues.

bootstrap is a minimal MeeGo file system, MIC2 can run very smoothly on it using chroot mode. You can use the below command to create a bootstrap:

<pre>
sudo mic-create-bootstrap -n trunk -k /your/repo/cache/path -r http://repo.meego.com/MeeGo/builds/trunk/latest/repos/oss/ia32/packages/ -o /your/final/bootstrap
</pre>

NOTE: The repo-url specific for your needs may differ

-n is used to specify repository name, if you have its cache before, it can reduce runtime dramatically to use it with -k option, -k is used to specify your repository cache dir, -r is used to specify MeeGo main repository.

Once you created your bootstrap, you can use this bootstrap to run MIC2 as follows

<pre>
sudo mic-image-creator --bootstrap=/your/final/bootstrap --format=livecd --config=default.ks --cache=/your/repo/cache/path
</pre>

Alternatively, you can create and use bootstrap in one mic-image-creator run, as follows

<pre>
sudo mic-image-creator --build-bootstrap --bootstrap=/your/final/bootstrap --format=livecd --config=default.ks --cache=/your/repo/cache/path
</pre>

== Running mic-image-writer ==

mic-image-writer writes a Meego image to a USB disk as an alternative to dd.

mic-image-writer can run in both console mode and GUI mode. It can decide which mode to run, according to current system environment. You can also use a given option to force it to run in some other mode. Run 'mic-image-writer --help' to get usage information:

<pre>
Usage: mic-image-writer [options] [image file]

Options:
-h, --help Show this help message and exit
-c, --console Run in console mode
-g, --gui Run in GUI mod
</pre>
Here is a run example in console mode:

<pre>
$ sudo mic-image-writer meego-xxx.img
Available usb disk:
[1] /dev/sdc: SanDisk USB Flash Drive
[2] /dev/sdb: SanDisk U3 Cruzer Micro
Please choice [1..2] ? 2
Source: /myhome/meego-xxx.img
Target: /dev/sdb
Image size: 559 MB
Estimated time: 55 seconds
Elapsed time: 64, progress: 100% 8944+0 records in
8944+0 records out
586153984 bytes (586 MB) copied, 63.0486 s, 9.3 MB/s
</pre>

mic-image-writer can estimate how long it will take to write the given image to your USB disk and reports current writing progress. It automatically unmounts your USB disk, if it is mounted. If your USB can't be unmounted, it will terminate.

If you love UI mode, you can run it in X enviroment. The command with the added -g flag:

<pre>
sudo mic-image-writer -g meego-xxx.img
</pre>

Image name is optional.

== Running mic-image-convertor ==

It's very easy to use:

<pre>
sudo mic-image-convertor --source-image=InputImage --target-format=Targegformat

sudo mic-image-convertor -I InputImage -T Targegformat
</pre>

For example, to translate a KVM raw image to livecd image, just type:

<pre>
sudo mic-image-convertor --source-image=meego-core-200902200545/meego-core-200902200545-sda.raw --target-format=livecd
</pre>

A new livecd image of meego-converted-from-raw-200902201804.iso is generated. The tool can detect the type of input image, either raw or vmdk.

This tool is very useful. For example, the developer can launch a virtual machine running MeeGo v2 and make whatever changes on the virtual system like yum install/remove a package, scp a source tarball to VM and build and try, and etc. Then with a simple "sync" or shutdown of VM, the VM image now contains his changes. With this tool, the VM image can be transformed to a live image and burned to a USB flash disk. Now developers can have final verifications in a target device, with changes in the live system.

== Running mic-chroot ==

There are two major usage models for mic-chroot for developers.

'''chroot directly into the image to use it as a development environment, then optionally create a new image based off of your changes'''
<pre>
sudo mic-chroot -c livecd meego-core-200903131337.iso
</pre>

The above command would present a chroot, using the livecd image, to developers with some bind mounts like /proc /sys /dev/pts and /parentroot. With those bind mounts, developers now can easily exchange files in chroot env with host /parentroot, and conduct yum install, yum remove and any other network related operations. After done and typing "exit", a new live ISO image is created from the chroot env with the changes developers made.

'''Unpack and modify the image's filesystem (which you can save), and create a new image based off of your changes'''

Sometimes, developers want to keep the chroot env, so that they can do multiple changes in that root file system at different times. So they want to execute following:

<pre>
sudo mic-chroot -s my-chroot-fs --unpack-only meego-core-200903131337.iso --bind-mounts=/proc:/proc;/:/parentroot;/sys:/sys;/dev/pts:/dev/pts
</pre>

The above command creates a folder called 'my-chroot-fs' in the current directory, using the chroot environment from the livecd image. Of course, if one forgets to add the --bind-mounts options, you'll need to manually do the bind mounting yourself. Don't forget copying /etc/reslov.conf into my-chroot-fs if you need to use DNS. Should you wish to create an image from the chroot, just execute following to create a livecd image

<pre>
sudo mic-chroot -c livecd --convert-only my-chroot-fs/
</pre>

== Enabling Autoinstallation ==

You need to copy a kickstart file into /root/mic2-ks.cfg which is used for
automated installation of the image. To activate autoinstall mode, boot with autoinst on the command line
or add --menus=autoinst to the bootloader directive in the kickstart file you use to
create the image.

= Development Release Processes =

http://wiki.meego.com/MIC2_Development_Release_Processes

= Known issues =

* MIC2 is not compatible with Ubuntu 8.04 (Yum package compatibility)
* MIC2 is not compatible with the initial Ubuntu 9.04. Make sure you have package libsqlite3-0 of 3.6.10-1ubuntu0.2 or later.
* MIC2 has some issues on Debian, please refer to [[MIC on Debian]] to get installation instructions

= Troubleshooting =

You can file a bug on http://bugzilla.meego.com/enter_bug.cgi?product=Development%20Tools (Note: you should select MIC for component) if you run into any MIC2-related issue, bugzilla can track your issue faster and more efficiently.

===libgcc related issues===
<pre>
libgcc_s.so.1 must be installed for pthread_cancel to work"

"Error: failed to create image : '/sbin/mksquashfs /var/tmp/imgcreate-FKCSsk/iso-u8xCPh/LiveOS/osmin /var/tmp/imgcreate-FKCSsk/iso-u8xCPh/LiveOS/osmin.img' exited with error (-6)
</pre>

This error occurs when MIC2 is unable to find the proper version of libgcc. This usually happens on x86_64 systems - MIC2 is looking for the 32 bit version of libgcc, but only the 64 bit version is installed. Installing the 32 bit version of libgcc should resolve this.

===General squashfs issues===
<pre>
"Error: failed to create image : '/sbin/mksquashfs /var/tmp/imgcreate-FKCSsk/iso-u8xCPh/LiveOS/osmin /var/tmp/imgcreate-FKCSsk/iso-u8xCPh/LiveOS/osmin.img' exited with error (-6)
</pre>

This error can also be an issue with the syslinux package. Try updating to the latest version for your distro.

===device-mapper issues===
<pre>
unable to remove open device
</pre>

This is a race condition with device-mapper in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=506644. Usually rerunning the MIC2 command will resolve this.

===python related issues===
<pre>
from urlgrabber.grabber import URLGrabber
ImportError: No module named urlgrabber.grabber
</pre>

Some people are using python they built themselves, so some python modules aren't under their python library path. For such error, only one way is not to use your own python but to use python your system installed.

===debian-based distros related issues===
On debian-based distros, we used pycentral to package mic2, but mic2 source installtion used distutils, so two kinds of installation have different installation path, if they exist there at the same time, it will result in some unpredictable errors to run mic2. To run it correctly, you can keep only one installation, source or binary.

Remove binary installation
<pre>
sudo apt-get remove mic2
</pre>

Remove source installation

Get python lib path
<pre>
$ python
Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38)
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import distutils.sysconfig
>>> print distutils.sysconfig.get_python_lib()
<PYTHONLIBPATH>
>>>
$
</pre>

Remove mic2 files
<pre>
$ sudo rm -rf <PYTHONLIBPATH>/mic
$ sudo rm -rf <PYTHONLIBPATH>/mic-0.*
$ sudo rm -f /usr/bin/mic
$ sudo rm -f /usr/bin/mic-*
$ sudo rm -f /usr/bin/moblin-*
</pre>

Note: You must replace <PYTHONLIBPATH> with the above python lib path

If program jams after mkfs.vfat, it might be due missing ''vol_id'' program. ''vol_id'' is replaced with ''blkid'' in new ubuntu versions. Try run ''/lib/udev/vol_id'', if it's missing you have troubles.

===ARM related issues===
<pre>
Traceback (most recent call last):
File "/usr/bin/mic-image-creator", line 856, in <module>
ret = main()
File "/usr/bin/mic-image-creator", line 682, in main
run_in_bootstrap(options.bootstrap, argv, bindmounts, arch = options.arch)
File "/usr/bin/mic-image-creator", line 261, in run_in_bootstrap
ret = subprocess.call(args, preexec_fn = chroot_bootstrap)
File "/usr/lib/python2.5/subprocess.py", line 444, in call
return Popen(*popenargs, **kwargs).wait()
File "/usr/lib/python2.5/subprocess.py", line 594, in __init__
errread, errwrite)
File "/usr/lib/python2.5/subprocess.py", line 1149, in _execute_child
raise child_exception
OSError: [Errno 8] Exec format error
</pre>

This error occurs when trying to build ARM images without passing ''--arch=armv7l'' to ''meego-image-creator''.

<pre>
Error: Requires qemu version >= 0.13 for armv7hl
</pre>

you should update the version of 'qemu-arm' or 'qemu-arm-static' to 0.13.0 or above.

Tips: if you encounter arm images creating failed, please try to run bootstrap mode, for armv7hl and armv7nhl is not supported in legacy mode.

===Proxy cache===

See http://bugs.meego.com/show_bug.cgi?id=2343

Some servers (such as with squid as a proxy) may cache more aggressively than
others, and as a result repomd.xml is invalid (old copy) and
references out of date metadata files (primary, comps, filelists, etc). This is
because the server is returning a cached/old copy of repomd.xml.

Proxy cache should be disabled in mic and yum.

= Advanced Hacking Tips =

===replace kernel in live image===

<pre>
$sudo mic-image-convertor --source-image=<your-netbook.img> --target-format=livecd --shell
</pre>

This command will give you a chroot environment of MeeGo, you can follow the below steps to replace the default kernel with a new one.

1). remove the old kernel

<pre>
# rpm -e kernel-netbook
</pre>

NOTE: execute the above command in chroot environment.

2). copy new kernel to chroot environment of MeeGo

<pre>
$sudo cp /path/to/kernel-*.rpm /var/tmp/imgcreate-*/install_root/
</pre>

NOTE: execute the above command in your host system.

/path/to/kernel-*.rpm is your new kernel to install, /var/tmp/imgcreate-*/install_root/ is the directory where chroot MeeGo mounted on.

3). install the new kernel

<pre>
# rpm -ivh /kernel-*.rpm
# rm /kernel-*.rpm
</pre>

NOTE: execute the above command in chroot environment.

After that, you can find out the new kernel in directory /boot/.

4). update contents of isolinux

<pre>
$sudo cp /var/tmp/imgcreate-*/install_root/boot/initrd-*.img /var/tmp/imgcreate-*/iso-*/isolinux/initrd0.img
$sudo cp /var/tmp/imgcreate-*/install_root/boot/vmlinuz-* /var/tmp/imgcreate-*/iso-*/isolinux/vmlinuz0
</pre>

NOTE: execute the above command in your host system.

5. create a new image
<pre>
#exit
</pre>
NOTE: execute the above command in chroot environment.

After following all the above steps, you'll have a new image.

===build btrfs image===
From version 0.20.1 on, mic2 can support btrfs, you can create btrfs image by change fstype=ext3 in your kickstart file to fstype=btrfs. A successful creation will depend on btrfs-progs (btrfs-tools on debian-based distros, btrfsprogs on openSUSE) and btrfs kernel module in your local system, the known issue is we can't create btrfs image on Fedora 11, the issue is the default btrfs kernel module has some issue which will make kernel panic, so for this case, you must make sure you have a stable and latest kernel and btrfs-progs 0.19 on your system. You'll need to build your kernel by yourself and use it to boot your system.

Btrfs-progs is a prerequisite tool, it includes /sbin/mkfs.btrfs, but its version must match btrfs kernel module, so you must ensure this, mic2 repo http://repo.meego.com/MeeGo/tools/repos/ has an issue which will install btrfs-progs 0.19 when you install mic2, this is an repo sync error, so please make sure you have your distro's btrfs-progs after mic2 is installed, if your distro's btrfs-progs version is 0.19, this isn't an issue, otherwise you must remove btrfs-progs installation introduced by mic2 and reinstall your distro's btrfs-progs.

How to build btrfs image on Fedora 11 or lower version?

# Download kernel-2.6.34 or kernel-2.6.35
# Configure btrfs as module
# make; make modules; make install; make modules_install
# Reboot your system using this built-newly kernel
# Install btrfs-progs 0.19

Done, you're ready for creating btrfs image.

===Metapackages, Patterns, and Repository Creation===
Meta-packages are discouraged in MeeGo. The preferred method is to use patterns in the repository (supported by both zypper and mic2). This is done by creating a patterns.xml file, which is a fairly simple XML file:

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<pattern xmlns:rpm="http://linux.duke.edu/metadata/rpm"
xmlns="http://novell.com/package/metadata/suse/pattern">
<name>meego-core</name>
<summary>MeeGo Core</summary>
<description>Packages needed for Compliance</description>
<uservisible/>
<category lang="en">Base Group</category>
<rpm:requires>
<rpm:entry name="pam"/>
<rpm:entry name="rootfiles"/>
<rpm:entry name="bash"/>
<rpm:entry name="sysvinit"/>

</rpm:requires>
</pattern>
</pre>

The detailed documentation for this XML schema may be found on the [http://en.opensuse.org/openSUSE:Standards_Rpm_Metadata OpenSuSe Wiki]. There is also a Relax NG schema found in the source code for [http://gitorious.org/opensuse/libzypp libzypp] (buried in the folder zypp/parser/yum/schema).

In MeeGo's [http://meego.gitorious.org/meego-os-base/package-groups package-groups], you can find several utilities, style sheets, and examples for how to create patterns and convert them to groups (comps).

Once you have both a patterns.xml and comps.xml file, you can create your repository like this. (For brevity, assuming a simple 'packages' repository.)

<code>
## Copy RPM packages to a folder, repos/
$ mkdir -p repos/repodata
$ cp -f patterns.xml comps.xml repos/repodata
$ createrepo -g repos/repodata/comps.xml repos/
$ modifyrepo repos/repodata/patterns.xml repos/repodata
</code>

Now, GPG sign your repos/repodata/repomd.xml file. Note that `modifyrepo` is a part of the `createrepo` package.

Image Configurations - KickStart Files

2011-07-06T13:40:13Z

Kevinwang: /* Generate .ks file from Kickstarter */

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.

Note that not all KickStart directives and options are supported for creating Meego images. MIC2 also adds some specific directives and options. More explained below

== Official Meego .ks files ==
The official Meego .ks files are here:

Formal release: http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build: http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the Meego images you create. Modify these .ks files as you wish to create tailored images.

We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.

== Modify your .ks ==
Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.

You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options

=== Change Partition, Setup and Bootloader options ===
These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc. You can change these depending on what your needs are.
''Example''

<pre>
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
auth --useshadow --enablemd5
part / --size 1500 --ondisk sda --fstype=ext3
rootpw meego
xconfig --startxonboot
bootloader --timeout=0 --append="quiet"
desktop --autologinuser=meego --defaultdesktop=xfce
user --name meego --groups audio,video --password meego
</pre>

=== Specify Repos ===
This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from which to make up your image. You can add official Meego repos, other remote repos, or your own local repos on your dev machine.

''Example''

<pre>
# This is a comment

# My first repo
repo --name=trunk --baseurl=http://mytrunk.myrepo.com

# My second repo
#repo --name=<repo-name-2> --baseurl=< url | local-repo-dir >
</pre>

'''NOTE:''' --name of the repo can be any unique alphanumeric name you give your repo, it can be anything. Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.

To create a repo you can point to on your local developer machine, you can run the following command:

<pre>
createrepo -d <local-dir>
</pre>

Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.

=== Add Packages Groups and Packages ===
* Groups
This specifies exactly what packages will be included in your image. Package groups can be specified with a "@" preceding it, as you can see from the example below:
<pre>
%packages
# Example adding pkg groups
@Core
@X for Netbooks
@Base
@Development Tools
@<my-PkgGroup1>
@<my-PkgGroup2>
</pre>

Package groups are defined in the 'patterns.xml' file, it defines the group names, and what packages are included in each package group, for example: http://repo.meego.com/MeeGo/releases/1.2.0/repos/oss/ia32/packages/repodata/patterns.xml

The Meego package groups are standard and common for MeeGo image creation. You can define your own package groups in your own non-Meego repos in local, if you are using those.

Please see here for more info in repositories about MeeGo package groups defination: https://meego.gitorious.org/meego-os-base/package-groups/

* Packages
You can also add individual packages to the image, for example.

<pre>
%packages
# Example adding individual pkgs
kernel-netbook
xorg-x11-server-Xorg-setuid
carrick
xorg-x11-drv-evtouch
<my-pkg-1>
<my-pkg-2>
%end
</pre>

=== How MIC2 picks a package when different versions are available ===
A common question is that, a packageA may has more than one copy with different versions residing in a repo(s) that your .ks is pointing to. How will the MIC2 know which one to pick?

* select the package with highest version number by default
''Example:''

In the repo(s) these are different versions of PackageA: 
PackageA-1.0
PackageA-2.0
PackageA-3.0
MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).

* select the package through "Epoch" version
There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file, such as:
<pre>
Name: <name>
Summary: <summary>
Epoch: 1
Version: <version>
</pre>

MIC2 will first look to compare the 'Epoch' version of the packages. All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.

''Example:'' 
PackageA-1.0 (Epoch not set)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-2.0 in this case. And it follow that:

''Example:'' 
PackageA-1.0 (Epoch=100)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-1.0.

Remember that Meego packages will not have 'Epoch' set, so if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.

=== Remove Packages ===

If you would like to make sure that a pkg should NOT be included, you can specify that with a '-' preceding the package name.

''Example:''
packages 'carrick' and 'package-xyz' will _not_ be included in the image
<pre>
%packages
# Example pkg groups
@Core

# Example adding individual pkgs
kernel-netbook

# Example removing individual pkgs
-carrick
-package-xyz
%end
</pre>

'''Note:''' all packages that depend on the package you want to remove should be removed also, otherwise MIC2 will ignore your request and keep that package in the image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it will include both of these pgks in the image.

=== Post scripts ===

You can also specify post-scripts to be run after the image is created.

''Example:''
<pre>
%post
# Example - saving some space
rm -f /boot/initrd*
rm -f /core*

# Example - Install working xorg.conf
if [ -f /usr/share/my.conf ]; then
cp /usr/share/my.conf /etc/X11/xorg.conf
fi

# Example - Tell alsa the correct audio card to use for your platform
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
robe.d/alsa.conf
%end
</pre>

== Generate .ks file from Kickstarter ==
You can also create .ks files by kickstarter from image-configurations.

=== Kickstarter ===
Kickstarter is a tool for create kickstart files to build meego images.

You can download it here: http://repo.meego.com/MeeGo/tools/repos/meego/trunk/noarch/

This tool is also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=kickstarter&project=Trunk

Example:
kickstarter --configs configurations.yaml --repos repos.yaml

Configuration file:
The "configuration.yaml" file here is an example only, for meego kickstart files, please get from the image-configurations package.

This file has the definition of configurations. The Configurations inherit from platforms first then from the DEFAULT section. The image configurations override the all other settings (in DEFAULT and platform sections).

Repo file:
This file contains a list of repositories to be used in the kickstart files.

=== image-configuration ===
You can get image-configurations noarch package here: http://download.meego.com/live/Trunk/standard/noarch/

The package of image-configurations also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=image-configurations&project=Trunk
The organization of image-configurations:

configuration.yaml -- default and platform generic configs, also point to external platform path, it's the entrance for kickstart.
repos.yaml -- a list of repositories to be used in the kickstart files
core -- path for image-configs under 'core' platform
compliance -- path for image-configs under 'compliance' platform
ivi -- path for image-configs under 'ivi' platform
handset -- path for image-configs under 'handset' platform
netbook -- path for image-configs under 'netbook' platform
tablet -- path for image-configs under 'tablet' platform
custom/part -- store partition definition
custom/scripts -- store postscripts definition

The followings are how does image-configurations manage those parts in .ks files.

This configurations.yaml file has a generic definition of configurations.
The Configurations inherit from platforms first then from the DEFAULT section.
The image configurations override all other settings
(in DEFAULT and platform sections).

Basically all common options should go to the DEFAULT section. If an options is
related to a specific platform, then that option should be added to the platform
section. Try to keep platforms clean and very generic, if needed, create a new
platform section and use it when many options for a new platform are common.

'''''Detail for the keywords'''''

"Name": description of the configuration file
Name: MeeGo Netbook/Nettop

"Schedule": When should this image be generated:
# *: always
# 0: Monday
# 1: Tuesday
# ...
# If no schedule keyword is present, then image will not be created

Schedule: "*"

"Active": if this image is active
Active: True

"Platform": Inherit from platform
Platform: NETBOOK

"Part": Partition specific configs
Part: qemu

# Part are stored in custom/part and referenced by part name

"Kernel": Based kernel
Kernel: kernel-adaptation-mrst

"Architecture": Based architecture
Architecture: ia32

"Mic2Options": MIC2 options to be used when creating this image
Mic2Options: "-f livecd"

"Desktop": Desktop type
Desktop: None

"Timezone"
Timezone: America/New_York

"FileName": The name of the configuration file
FileName: netbook-ia32

"Groups": package groups
Groups:
- MeeGo Netbook Desktop
- MeeGo Core
- Printing
- Games

"ExtraPackages": Additional packages that are not part of any group
ExtraPackages:
- chromium
- adobe-release
- flash-plugin

"Repos": Repos to use in addition to default repos, those are define in the repos.yaml file
Repos:
- adobe

"PostScripts": Post-scripts to be run after the image is installed
PostScripts:
- meegotouch-n900
- bootchart
- fstab-n900
- arch-armv7hl

# post-scripts are stored in custom/scripts and referenced by post-scripts name

Image Configurations - KickStart Files

2011-07-06T13:39:19Z

Kevinwang: /* Add Packages Groups and Packages */

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.

Note that not all KickStart directives and options are supported for creating Meego images. MIC2 also adds some specific directives and options. More explained below

== Official Meego .ks files ==
The official Meego .ks files are here:

Formal release: http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build: http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the Meego images you create. Modify these .ks files as you wish to create tailored images.

We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.

== Modify your .ks ==
Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.

You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options

=== Change Partition, Setup and Bootloader options ===
These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc. You can change these depending on what your needs are.
''Example''

<pre>
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
auth --useshadow --enablemd5
part / --size 1500 --ondisk sda --fstype=ext3
rootpw meego
xconfig --startxonboot
bootloader --timeout=0 --append="quiet"
desktop --autologinuser=meego --defaultdesktop=xfce
user --name meego --groups audio,video --password meego
</pre>

=== Specify Repos ===
This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from which to make up your image. You can add official Meego repos, other remote repos, or your own local repos on your dev machine.

''Example''

<pre>
# This is a comment

# My first repo
repo --name=trunk --baseurl=http://mytrunk.myrepo.com

# My second repo
#repo --name=<repo-name-2> --baseurl=< url | local-repo-dir >
</pre>

'''NOTE:''' --name of the repo can be any unique alphanumeric name you give your repo, it can be anything. Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.

To create a repo you can point to on your local developer machine, you can run the following command:

<pre>
createrepo -d <local-dir>
</pre>

Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.

=== Add Packages Groups and Packages ===
* Groups
This specifies exactly what packages will be included in your image. Package groups can be specified with a "@" preceding it, as you can see from the example below:
<pre>
%packages
# Example adding pkg groups
@Core
@X for Netbooks
@Base
@Development Tools
@<my-PkgGroup1>
@<my-PkgGroup2>
</pre>

Package groups are defined in the 'patterns.xml' file, it defines the group names, and what packages are included in each package group, for example: http://repo.meego.com/MeeGo/releases/1.2.0/repos/oss/ia32/packages/repodata/patterns.xml

The Meego package groups are standard and common for MeeGo image creation. You can define your own package groups in your own non-Meego repos in local, if you are using those.

Please see here for more info in repositories about MeeGo package groups defination: https://meego.gitorious.org/meego-os-base/package-groups/

* Packages
You can also add individual packages to the image, for example.

<pre>
%packages
# Example adding individual pkgs
kernel-netbook
xorg-x11-server-Xorg-setuid
carrick
xorg-x11-drv-evtouch
<my-pkg-1>
<my-pkg-2>
%end
</pre>

=== How MIC2 picks a package when different versions are available ===
A common question is that, a packageA may has more than one copy with different versions residing in a repo(s) that your .ks is pointing to. How will the MIC2 know which one to pick?

* select the package with highest version number by default
''Example:''

In the repo(s) these are different versions of PackageA: 
PackageA-1.0
PackageA-2.0
PackageA-3.0
MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).

* select the package through "Epoch" version
There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file, such as:
<pre>
Name: <name>
Summary: <summary>
Epoch: 1
Version: <version>
</pre>

MIC2 will first look to compare the 'Epoch' version of the packages. All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.

''Example:'' 
PackageA-1.0 (Epoch not set)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-2.0 in this case. And it follow that:

''Example:'' 
PackageA-1.0 (Epoch=100)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-1.0.

Remember that Meego packages will not have 'Epoch' set, so if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.

=== Remove Packages ===

If you would like to make sure that a pkg should NOT be included, you can specify that with a '-' preceding the package name.

''Example:''
packages 'carrick' and 'package-xyz' will _not_ be included in the image
<pre>
%packages
# Example pkg groups
@Core

# Example adding individual pkgs
kernel-netbook

# Example removing individual pkgs
-carrick
-package-xyz
%end
</pre>

'''Note:''' all packages that depend on the package you want to remove should be removed also, otherwise MIC2 will ignore your request and keep that package in the image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it will include both of these pgks in the image.

=== Post scripts ===

You can also specify post-scripts to be run after the image is created.

''Example:''
<pre>
%post
# Example - saving some space
rm -f /boot/initrd*
rm -f /core*

# Example - Install working xorg.conf
if [ -f /usr/share/my.conf ]; then
cp /usr/share/my.conf /etc/X11/xorg.conf
fi

# Example - Tell alsa the correct audio card to use for your platform
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
robe.d/alsa.conf
%end
</pre>

== Generate .ks file from Kickstarter ==
It's strongly recommended to create .ks files by kickstarter from image-configurations.

=== Kickstarter ===
Kickstarter is a tool for create kickstart files to build meego images.

You can download it here: http://repo.meego.com/MeeGo/tools/repos/meego/trunk/noarch/

This tool is also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=kickstarter&project=Trunk

Example:
kickstarter --configs configurations.yaml --repos repos.yaml

Configuration file:
The "configuration.yaml" file here is an example only, for meego kickstart files, please get from the image-configurations package.

This file has the definition of configurations. The Configurations inherit from platforms first then from the DEFAULT section. The image configurations override the all other settings (in DEFAULT and platform sections).

Repo file:
This file contains a list of repositories to be used in the kickstart files.

=== image-configuration ===
You can get image-configurations noarch package here: http://download.meego.com/live/Trunk/standard/noarch/

The package of image-configurations also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=image-configurations&project=Trunk
The organization of image-configurations:

configuration.yaml -- default and platform generic configs, also point to external platform path, it's the entrance for kickstart.
repos.yaml -- a list of repositories to be used in the kickstart files
core -- path for image-configs under 'core' platform
compliance -- path for image-configs under 'compliance' platform
ivi -- path for image-configs under 'ivi' platform
handset -- path for image-configs under 'handset' platform
netbook -- path for image-configs under 'netbook' platform
tablet -- path for image-configs under 'tablet' platform
custom/part -- store partition definition
custom/scripts -- store postscripts definition

The followings are how does image-configurations manage those parts in .ks files.

This configurations.yaml file has a generic definition of configurations.
The Configurations inherit from platforms first then from the DEFAULT section.
The image configurations override all other settings
(in DEFAULT and platform sections).

Basically all common options should go to the DEFAULT section. If an options is
related to a specific platform, then that option should be added to the platform
section. Try to keep platforms clean and very generic, if needed, create a new
platform section and use it when many options for a new platform are common.

'''''Detail for the keywords'''''

"Name": description of the configuration file
Name: MeeGo Netbook/Nettop

"Schedule": When should this image be generated:
# *: always
# 0: Monday
# 1: Tuesday
# ...
# If no schedule keyword is present, then image will not be created

Schedule: "*"

"Active": if this image is active
Active: True

"Platform": Inherit from platform
Platform: NETBOOK

"Part": Partition specific configs
Part: qemu

# Part are stored in custom/part and referenced by part name

"Kernel": Based kernel
Kernel: kernel-adaptation-mrst

"Architecture": Based architecture
Architecture: ia32

"Mic2Options": MIC2 options to be used when creating this image
Mic2Options: "-f livecd"

"Desktop": Desktop type
Desktop: None

"Timezone"
Timezone: America/New_York

"FileName": The name of the configuration file
FileName: netbook-ia32

"Groups": package groups
Groups:
- MeeGo Netbook Desktop
- MeeGo Core
- Printing
- Games

"ExtraPackages": Additional packages that are not part of any group
ExtraPackages:
- chromium
- adobe-release
- flash-plugin

"Repos": Repos to use in addition to default repos, those are define in the repos.yaml file
Repos:
- adobe

"PostScripts": Post-scripts to be run after the image is installed
PostScripts:
- meegotouch-n900
- bootchart
- fstab-n900
- arch-armv7hl

# post-scripts are stored in custom/scripts and referenced by post-scripts name

Image Configurations - KickStart Files

2011-07-06T13:37:59Z

Kevinwang: /* Official Meego .ks files */

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.

Note that not all KickStart directives and options are supported for creating Meego images. MIC2 also adds some specific directives and options. More explained below

== Official Meego .ks files ==
The official Meego .ks files are here:

Formal release: http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build: http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the Meego images you create. Modify these .ks files as you wish to create tailored images.

We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.

== Modify your .ks ==
Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.

You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options

=== Change Partition, Setup and Bootloader options ===
These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc. You can change these depending on what your needs are.
''Example''

<pre>
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
auth --useshadow --enablemd5
part / --size 1500 --ondisk sda --fstype=ext3
rootpw meego
xconfig --startxonboot
bootloader --timeout=0 --append="quiet"
desktop --autologinuser=meego --defaultdesktop=xfce
user --name meego --groups audio,video --password meego
</pre>

=== Specify Repos ===
This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from which to make up your image. You can add official Meego repos, other remote repos, or your own local repos on your dev machine.

''Example''

<pre>
# This is a comment

# My first repo
repo --name=trunk --baseurl=http://mytrunk.myrepo.com

# My second repo
#repo --name=<repo-name-2> --baseurl=< url | local-repo-dir >
</pre>

'''NOTE:''' --name of the repo can be any unique alphanumeric name you give your repo, it can be anything. Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.

To create a repo you can point to on your local developer machine, you can run the following command:

<pre>
createrepo -d <local-dir>
</pre>

Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.

=== Add Packages Groups and Packages ===
* Groups
This specifies exactly what packages will be included in your image. Package groups can be specified with a "@" preceding it, as you can see from the example below:
<pre>
%packages
# Example adding pkg groups
@Core
@X for Netbooks
@Base
@Development Tools
@<my-PkgGroup1>
@<my-PkgGroup2>
</pre>

Package groups are defined in the 'patterns.xml' file, it defines the group names, and what packages are included in each package group, for example:
http://repo.meego.com/MeeGo/releases/1.2.0/repos/oss/ia32/packages/repodata/patterns.xml

The Meego package groups are standard and common for MeeGo image creation. You can define your own package groups in your own non-Meego repos in local, if you are using those.

Please see here for more info in repositories about MeeGo package groups defination:
https://meego.gitorious.org/meego-os-base/package-groups/

* Packages
You can also add individual packages to the image, for example.

<pre>
%packages
# Example adding individual pkgs
kernel-netbook
xorg-x11-server-Xorg-setuid
carrick
xorg-x11-drv-evtouch
<my-pkg-1>
<my-pkg-2>
%end
</pre>

=== How MIC2 picks a package when different versions are available ===
A common question is that, a packageA may has more than one copy with different versions residing in a repo(s) that your .ks is pointing to. How will the MIC2 know which one to pick?

* select the package with highest version number by default
''Example:''

In the repo(s) these are different versions of PackageA: 
PackageA-1.0
PackageA-2.0
PackageA-3.0
MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).

* select the package through "Epoch" version
There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file, such as:
<pre>
Name: <name>
Summary: <summary>
Epoch: 1
Version: <version>
</pre>

MIC2 will first look to compare the 'Epoch' version of the packages. All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.

''Example:'' 
PackageA-1.0 (Epoch not set)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-2.0 in this case. And it follow that:

''Example:'' 
PackageA-1.0 (Epoch=100)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-1.0.

Remember that Meego packages will not have 'Epoch' set, so if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.

=== Remove Packages ===

If you would like to make sure that a pkg should NOT be included, you can specify that with a '-' preceding the package name.

''Example:''
packages 'carrick' and 'package-xyz' will _not_ be included in the image
<pre>
%packages
# Example pkg groups
@Core

# Example adding individual pkgs
kernel-netbook

# Example removing individual pkgs
-carrick
-package-xyz
%end
</pre>

'''Note:''' all packages that depend on the package you want to remove should be removed also, otherwise MIC2 will ignore your request and keep that package in the image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it will include both of these pgks in the image.

=== Post scripts ===

You can also specify post-scripts to be run after the image is created.

''Example:''
<pre>
%post
# Example - saving some space
rm -f /boot/initrd*
rm -f /core*

# Example - Install working xorg.conf
if [ -f /usr/share/my.conf ]; then
cp /usr/share/my.conf /etc/X11/xorg.conf
fi

# Example - Tell alsa the correct audio card to use for your platform
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
robe.d/alsa.conf
%end
</pre>

== Generate .ks file from Kickstarter ==
It's strongly recommended to create .ks files by kickstarter from image-configurations.

=== Kickstarter ===
Kickstarter is a tool for create kickstart files to build meego images.

You can download it here: http://repo.meego.com/MeeGo/tools/repos/meego/trunk/noarch/

This tool is also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=kickstarter&project=Trunk

Example:
kickstarter --configs configurations.yaml --repos repos.yaml

Configuration file:
The "configuration.yaml" file here is an example only, for meego kickstart files, please get from the image-configurations package.

This file has the definition of configurations. The Configurations inherit from platforms first then from the DEFAULT section. The image configurations override the all other settings (in DEFAULT and platform sections).

Repo file:
This file contains a list of repositories to be used in the kickstart files.

=== image-configuration ===
You can get image-configurations noarch package here: http://download.meego.com/live/Trunk/standard/noarch/

The package of image-configurations also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=image-configurations&project=Trunk
The organization of image-configurations:

configuration.yaml -- default and platform generic configs, also point to external platform path, it's the entrance for kickstart.
repos.yaml -- a list of repositories to be used in the kickstart files
core -- path for image-configs under 'core' platform
compliance -- path for image-configs under 'compliance' platform
ivi -- path for image-configs under 'ivi' platform
handset -- path for image-configs under 'handset' platform
netbook -- path for image-configs under 'netbook' platform
tablet -- path for image-configs under 'tablet' platform
custom/part -- store partition definition
custom/scripts -- store postscripts definition

The followings are how does image-configurations manage those parts in .ks files.

This configurations.yaml file has a generic definition of configurations.
The Configurations inherit from platforms first then from the DEFAULT section.
The image configurations override all other settings
(in DEFAULT and platform sections).

Basically all common options should go to the DEFAULT section. If an options is
related to a specific platform, then that option should be added to the platform
section. Try to keep platforms clean and very generic, if needed, create a new
platform section and use it when many options for a new platform are common.

'''''Detail for the keywords'''''

"Name": description of the configuration file
Name: MeeGo Netbook/Nettop

"Schedule": When should this image be generated:
# *: always
# 0: Monday
# 1: Tuesday
# ...
# If no schedule keyword is present, then image will not be created

Schedule: "*"

"Active": if this image is active
Active: True

"Platform": Inherit from platform
Platform: NETBOOK

"Part": Partition specific configs
Part: qemu

# Part are stored in custom/part and referenced by part name

"Kernel": Based kernel
Kernel: kernel-adaptation-mrst

"Architecture": Based architecture
Architecture: ia32

"Mic2Options": MIC2 options to be used when creating this image
Mic2Options: "-f livecd"

"Desktop": Desktop type
Desktop: None

"Timezone"
Timezone: America/New_York

"FileName": The name of the configuration file
FileName: netbook-ia32

"Groups": package groups
Groups:
- MeeGo Netbook Desktop
- MeeGo Core
- Printing
- Games

"ExtraPackages": Additional packages that are not part of any group
ExtraPackages:
- chromium
- adobe-release
- flash-plugin

"Repos": Repos to use in addition to default repos, those are define in the repos.yaml file
Repos:
- adobe

"PostScripts": Post-scripts to be run after the image is installed
PostScripts:
- meegotouch-n900
- bootchart
- fstab-n900
- arch-armv7hl

# post-scripts are stored in custom/scripts and referenced by post-scripts name

Image Configurations - KickStart Files

2011-07-06T13:23:18Z

Kevinwang: /* Kickstart from image-configurations */

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.

Note that not all KickStart directives and options are supported for creating Meego images. MIC2 also adds some specific directives and options. More explained below

== Official Meego .ks files ==
The official Meego .ks files are here:

Formal release:
http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build:
http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the Meego images you create. Modify these .ks files as you wish to create tailored images.

We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.

== Modify your .ks ==
Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.

You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options

=== Change Partition, Setup and Bootloader options ===
These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc. You can change these depending on what your needs are.
''Example''

<pre>
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
auth --useshadow --enablemd5
part / --size 1500 --ondisk sda --fstype=ext3
rootpw meego
xconfig --startxonboot
bootloader --timeout=0 --append="quiet"
desktop --autologinuser=meego --defaultdesktop=xfce
user --name meego --groups audio,video --password meego
</pre>

=== Specify Repos ===
This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from which to make up your image. You can add official Meego repos, other remote repos, or your own local repos on your dev machine.

''Example''

<pre>
# This is a comment

# My first repo
repo --name=trunk --baseurl=http://mytrunk.myrepo.com

# My second repo
#repo --name=<repo-name-2> --baseurl=< url | local-repo-dir >
</pre>

'''NOTE:''' --name of the repo can be any unique alphanumeric name you give your repo, it can be anything. Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.

To create a repo you can point to on your local developer machine, you can run the following command:

<pre>
createrepo -d <local-dir>
</pre>

Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.

=== Add Packages Groups and Packages ===
* Groups
This specifies exactly what packages will be included in your image. Package groups can be specified with a "@" preceding it, as you can see from the example below:
<pre>
%packages
# Example adding pkg groups
@Core
@X for Netbooks
@Base
@Development Tools
@<my-PkgGroup1>
@<my-PkgGroup2>
</pre>

Package groups are defined in the 'patterns.xml' file, it defines the group names, and what packages are included in each package group, for example:
http://repo.meego.com/MeeGo/releases/1.2.0/repos/oss/ia32/packages/repodata/patterns.xml

The Meego package groups are standard and common for MeeGo image creation. You can define your own package groups in your own non-Meego repos in local, if you are using those.

Please see here for more info in repositories about MeeGo package groups defination:
https://meego.gitorious.org/meego-os-base/package-groups/

* Packages
You can also add individual packages to the image, for example.

<pre>
%packages
# Example adding individual pkgs
kernel-netbook
xorg-x11-server-Xorg-setuid
carrick
xorg-x11-drv-evtouch
<my-pkg-1>
<my-pkg-2>
%end
</pre>

=== How MIC2 picks a package when different versions are available ===
A common question is that, a packageA may has more than one copy with different versions residing in a repo(s) that your .ks is pointing to. How will the MIC2 know which one to pick?

* select the package with highest version number by default
''Example:''

In the repo(s) these are different versions of PackageA: 
PackageA-1.0
PackageA-2.0
PackageA-3.0
MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).

* select the package through "Epoch" version
There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file, such as:
<pre>
Name: <name>
Summary: <summary>
Epoch: 1
Version: <version>
</pre>

MIC2 will first look to compare the 'Epoch' version of the packages. All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.

''Example:'' 
PackageA-1.0 (Epoch not set)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-2.0 in this case. And it follow that:

''Example:'' 
PackageA-1.0 (Epoch=100)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-1.0.

Remember that Meego packages will not have 'Epoch' set, so if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.

=== Remove Packages ===

If you would like to make sure that a pkg should NOT be included, you can specify that with a '-' preceding the package name.

''Example:''
packages 'carrick' and 'package-xyz' will _not_ be included in the image
<pre>
%packages
# Example pkg groups
@Core

# Example adding individual pkgs
kernel-netbook

# Example removing individual pkgs
-carrick
-package-xyz
%end
</pre>

'''Note:''' all packages that depend on the package you want to remove should be removed also, otherwise MIC2 will ignore your request and keep that package in the image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it will include both of these pgks in the image.

=== Post scripts ===

You can also specify post-scripts to be run after the image is created.

''Example:''
<pre>
%post
# Example - saving some space
rm -f /boot/initrd*
rm -f /core*

# Example - Install working xorg.conf
if [ -f /usr/share/my.conf ]; then
cp /usr/share/my.conf /etc/X11/xorg.conf
fi

# Example - Tell alsa the correct audio card to use for your platform
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
robe.d/alsa.conf
%end
</pre>

== Generate .ks file from Kickstarter ==
It's strongly recommended to create .ks files by kickstarter from image-configurations.

=== Kickstarter ===
Kickstarter is a tool for create kickstart files to build meego images.

You can download it here: http://repo.meego.com/MeeGo/tools/repos/meego/trunk/noarch/

This tool is also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=kickstarter&project=Trunk

Example:
kickstarter --configs configurations.yaml --repos repos.yaml

Configuration file:
The "configuration.yaml" file here is an example only, for meego kickstart files, please get from the image-configurations package.

This file has the definition of configurations. The Configurations inherit from platforms first then from the DEFAULT section. The image configurations override the all other settings (in DEFAULT and platform sections).

Repo file:
This file contains a list of repositories to be used in the kickstart files.

=== image-configuration ===
You can get image-configurations noarch package here: http://download.meego.com/live/Trunk/standard/noarch/

The package of image-configurations also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=image-configurations&project=Trunk
The organization of image-configurations:

configuration.yaml -- default and platform generic configs, also point to external platform path, it's the entrance for kickstart.
repos.yaml -- a list of repositories to be used in the kickstart files
core -- path for image-configs under 'core' platform
compliance -- path for image-configs under 'compliance' platform
ivi -- path for image-configs under 'ivi' platform
handset -- path for image-configs under 'handset' platform
netbook -- path for image-configs under 'netbook' platform
tablet -- path for image-configs under 'tablet' platform
custom/part -- store partition definition
custom/scripts -- store postscripts definition

The followings are how does image-configurations manage those parts in .ks files.

This configurations.yaml file has a generic definition of configurations.
The Configurations inherit from platforms first then from the DEFAULT section.
The image configurations override all other settings
(in DEFAULT and platform sections).

Basically all common options should go to the DEFAULT section. If an options is
related to a specific platform, then that option should be added to the platform
section. Try to keep platforms clean and very generic, if needed, create a new
platform section and use it when many options for a new platform are common.

'''''Detail for the keywords'''''

"Name": description of the configuration file
Name: MeeGo Netbook/Nettop

"Schedule": When should this image be generated:
# *: always
# 0: Monday
# 1: Tuesday
# ...
# If no schedule keyword is present, then image will not be created

Schedule: "*"

"Active": if this image is active
Active: True

"Platform": Inherit from platform
Platform: NETBOOK

"Part": Partition specific configs
Part: qemu

# Part are stored in custom/part and referenced by part name

"Kernel": Based kernel
Kernel: kernel-adaptation-mrst

"Architecture": Based architecture
Architecture: ia32

"Mic2Options": MIC2 options to be used when creating this image
Mic2Options: "-f livecd"

"Desktop": Desktop type
Desktop: None

"Timezone"
Timezone: America/New_York

"FileName": The name of the configuration file
FileName: netbook-ia32

"Groups": package groups
Groups:
- MeeGo Netbook Desktop
- MeeGo Core
- Printing
- Games

"ExtraPackages": Additional packages that are not part of any group
ExtraPackages:
- chromium
- adobe-release
- flash-plugin

"Repos": Repos to use in addition to default repos, those are define in the repos.yaml file
Repos:
- adobe

"PostScripts": Post-scripts to be run after the image is installed
PostScripts:
- meegotouch-n900
- bootchart
- fstab-n900
- arch-armv7hl

# post-scripts are stored in custom/scripts and referenced by post-scripts name

Image Configurations - KickStart Files

2011-07-06T13:21:44Z

Kevinwang: /* image-configuration */

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.

Note that not all KickStart directives and options are supported for creating Meego images. MIC2 also adds some specific directives and options. More explained below

== Official Meego .ks files ==
The official Meego .ks files are here:

Formal release:
http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build:
http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the Meego images you create. Modify these .ks files as you wish to create tailored images.

We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.

== Modify your .ks ==
Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.

You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options

=== Change Partition, Setup and Bootloader options ===
These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc. You can change these depending on what your needs are.
''Example''

<pre>
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
auth --useshadow --enablemd5
part / --size 1500 --ondisk sda --fstype=ext3
rootpw meego
xconfig --startxonboot
bootloader --timeout=0 --append="quiet"
desktop --autologinuser=meego --defaultdesktop=xfce
user --name meego --groups audio,video --password meego
</pre>

=== Specify Repos ===
This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from which to make up your image. You can add official Meego repos, other remote repos, or your own local repos on your dev machine.

''Example''

<pre>
# This is a comment

# My first repo
repo --name=trunk --baseurl=http://mytrunk.myrepo.com

# My second repo
#repo --name=<repo-name-2> --baseurl=< url | local-repo-dir >
</pre>

'''NOTE:''' --name of the repo can be any unique alphanumeric name you give your repo, it can be anything. Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.

To create a repo you can point to on your local developer machine, you can run the following command:

<pre>
createrepo -d <local-dir>
</pre>

Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.

=== Add Packages Groups and Packages ===
* Groups
This specifies exactly what packages will be included in your image. Package groups can be specified with a "@" preceding it, as you can see from the example below:
<pre>
%packages
# Example adding pkg groups
@Core
@X for Netbooks
@Base
@Development Tools
@<my-PkgGroup1>
@<my-PkgGroup2>
</pre>

Package groups are defined in the 'patterns.xml' file, it defines the group names, and what packages are included in each package group, for example:
http://repo.meego.com/MeeGo/releases/1.2.0/repos/oss/ia32/packages/repodata/patterns.xml

The Meego package groups are standard and common for MeeGo image creation. You can define your own package groups in your own non-Meego repos in local, if you are using those.

Please see here for more info in repositories about MeeGo package groups defination:
https://meego.gitorious.org/meego-os-base/package-groups/

* Packages
You can also add individual packages to the image, for example.

<pre>
%packages
# Example adding individual pkgs
kernel-netbook
xorg-x11-server-Xorg-setuid
carrick
xorg-x11-drv-evtouch
<my-pkg-1>
<my-pkg-2>
%end
</pre>

=== How MIC2 picks a package when different versions are available ===
A common question is that, a packageA may has more than one copy with different versions residing in a repo(s) that your .ks is pointing to. How will the MIC2 know which one to pick?

* select the package with highest version number by default
''Example:''

In the repo(s) these are different versions of PackageA: 
PackageA-1.0
PackageA-2.0
PackageA-3.0
MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).

* select the package through "Epoch" version
There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file, such as:
<pre>
Name: <name>
Summary: <summary>
Epoch: 1
Version: <version>
</pre>

MIC2 will first look to compare the 'Epoch' version of the packages. All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.

''Example:'' 
PackageA-1.0 (Epoch not set)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-2.0 in this case. And it follow that:

''Example:'' 
PackageA-1.0 (Epoch=100)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-1.0.

Remember that Meego packages will not have 'Epoch' set, so if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.

=== Remove Packages ===

If you would like to make sure that a pkg should NOT be included, you can specify that with a '-' preceding the package name.

''Example:''
packages 'carrick' and 'package-xyz' will _not_ be included in the image
<pre>
%packages
# Example pkg groups
@Core

# Example adding individual pkgs
kernel-netbook

# Example removing individual pkgs
-carrick
-package-xyz
%end
</pre>

'''Note:''' all packages that depend on the package you want to remove should be removed also, otherwise MIC2 will ignore your request and keep that package in the image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it will include both of these pgks in the image.

=== Post scripts ===

You can also specify post-scripts to be run after the image is created.

''Example:''
<pre>
%post
# Example - saving some space
rm -f /boot/initrd*
rm -f /core*

# Example - Install working xorg.conf
if [ -f /usr/share/my.conf ]; then
cp /usr/share/my.conf /etc/X11/xorg.conf
fi

# Example - Tell alsa the correct audio card to use for your platform
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
robe.d/alsa.conf
%end
</pre>

== Generate .ks file from Kickstarter ==
It's strongly recommended to create .ks files by kickstarter from image-configurations.

=== Kickstarter ===
Kickstarter is a tool for create kickstart files to build meego images.

You can download it here: http://repo.meego.com/MeeGo/tools/repos/meego/trunk/noarch/

This tool is also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=kickstarter&project=Trunk

Example:
kickstarter --configs configurations.yaml --repos repos.yaml

Configuration file:
The "configuration.yaml" file here is an example only, for meego kickstart files, please get from the image-configurations package.

This file has the definition of configurations. The Configurations inherit from platforms first then from the DEFAULT section. The image configurations override the all other settings (in DEFAULT and platform sections).

Repo file:
This file contains a list of repositories to be used in the kickstart files.

== Kickstart from image-configurations ==

It's strongly recommended to create .ks files by kickstarter from image-configurations.

You can get image-configurations noarch package here: http://download.meego.com/live/Trunk/standard/noarch/

The package of image-configurations also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=image-configurations&project=Trunk

The followings are how does image-configurations manage those parts in .ks files.

This configurations.yaml file has a generic definition of configurations.
The Configurations inherit from platforms first then from the DEFAULT section.
The image configurations override all other settings
(in DEFAULT and platform sections).

Basically all common options should go to the DEFAULT section. If an options is
related to a specific platform, then that option should be added to the platform
section. Try to keep platforms clean and very generic, if needed, create a new
platform section and use it when many options for a new platform are common.

'''''Detail for the keywords'''''

"Name": description of the configuration file
Name: MeeGo Netbook/Nettop

"Schedule": When should this image be generated:
# *: always
# 0: Monday
# 1: Tuesday
# ...
# If no schedule keyword is present, then image will not be created

Schedule: "*"

"Active": if this image is active
Active: True

"Platform": Inherit from platform
Platform: NETBOOK

"Part": Partition specific configs
Part: qemu

# Part are stored in custom/part and referenced by part name

"Kernel": Based kernel
Kernel: kernel-adaptation-mrst

"Architecture": Based architecture
Architecture: ia32

"Mic2Options": MIC2 options to be used when creating this image
Mic2Options: "-f livecd"

"Desktop": Desktop type
Desktop: None

"Timezone"
Timezone: America/New_York

"FileName": The name of the configuration file
FileName: netbook-ia32

"Groups": package groups
Groups:
- MeeGo Netbook Desktop
- MeeGo Core
- Printing
- Games

"ExtraPackages": Additional packages that are not part of any group
ExtraPackages:
- chromium
- adobe-release
- flash-plugin

"Repos": Repos to use in addition to default repos, those are define in the repos.yaml file
Repos:
- adobe

"PostScripts": Post-scripts to be run after the image is installed
PostScripts:
- meegotouch-n900
- bootchart
- fstab-n900
- arch-armv7hl

# post-scripts are stored in custom/scripts and referenced by post-scripts name

Image Configurations - KickStart Files

2011-07-06T13:19:29Z

Kevinwang: /* Kickstarter */

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.

Note that not all KickStart directives and options are supported for creating Meego images. MIC2 also adds some specific directives and options. More explained below

== Official Meego .ks files ==
The official Meego .ks files are here:

Formal release:
http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build:
http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the Meego images you create. Modify these .ks files as you wish to create tailored images.

We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.

== Modify your .ks ==
Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.

You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options

=== Change Partition, Setup and Bootloader options ===
These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc. You can change these depending on what your needs are.
''Example''

<pre>
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
auth --useshadow --enablemd5
part / --size 1500 --ondisk sda --fstype=ext3
rootpw meego
xconfig --startxonboot
bootloader --timeout=0 --append="quiet"
desktop --autologinuser=meego --defaultdesktop=xfce
user --name meego --groups audio,video --password meego
</pre>

=== Specify Repos ===
This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from which to make up your image. You can add official Meego repos, other remote repos, or your own local repos on your dev machine.

''Example''

<pre>
# This is a comment

# My first repo
repo --name=trunk --baseurl=http://mytrunk.myrepo.com

# My second repo
#repo --name=<repo-name-2> --baseurl=< url | local-repo-dir >
</pre>

'''NOTE:''' --name of the repo can be any unique alphanumeric name you give your repo, it can be anything. Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.

To create a repo you can point to on your local developer machine, you can run the following command:

<pre>
createrepo -d <local-dir>
</pre>

Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.

=== Add Packages Groups and Packages ===
* Groups
This specifies exactly what packages will be included in your image. Package groups can be specified with a "@" preceding it, as you can see from the example below:
<pre>
%packages
# Example adding pkg groups
@Core
@X for Netbooks
@Base
@Development Tools
@<my-PkgGroup1>
@<my-PkgGroup2>
</pre>

Package groups are defined in the 'patterns.xml' file, it defines the group names, and what packages are included in each package group, for example:
http://repo.meego.com/MeeGo/releases/1.2.0/repos/oss/ia32/packages/repodata/patterns.xml

The Meego package groups are standard and common for MeeGo image creation. You can define your own package groups in your own non-Meego repos in local, if you are using those.

Please see here for more info in repositories about MeeGo package groups defination:
https://meego.gitorious.org/meego-os-base/package-groups/

* Packages
You can also add individual packages to the image, for example.

<pre>
%packages
# Example adding individual pkgs
kernel-netbook
xorg-x11-server-Xorg-setuid
carrick
xorg-x11-drv-evtouch
<my-pkg-1>
<my-pkg-2>
%end
</pre>

=== How MIC2 picks a package when different versions are available ===
A common question is that, a packageA may has more than one copy with different versions residing in a repo(s) that your .ks is pointing to. How will the MIC2 know which one to pick?

* select the package with highest version number by default
''Example:''

In the repo(s) these are different versions of PackageA: 
PackageA-1.0
PackageA-2.0
PackageA-3.0
MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).

* select the package through "Epoch" version
There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file, such as:
<pre>
Name: <name>
Summary: <summary>
Epoch: 1
Version: <version>
</pre>

MIC2 will first look to compare the 'Epoch' version of the packages. All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.

''Example:'' 
PackageA-1.0 (Epoch not set)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-2.0 in this case. And it follow that:

''Example:'' 
PackageA-1.0 (Epoch=100)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-1.0.

Remember that Meego packages will not have 'Epoch' set, so if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.

=== Remove Packages ===

If you would like to make sure that a pkg should NOT be included, you can specify that with a '-' preceding the package name.

''Example:''
packages 'carrick' and 'package-xyz' will _not_ be included in the image
<pre>
%packages
# Example pkg groups
@Core

# Example adding individual pkgs
kernel-netbook

# Example removing individual pkgs
-carrick
-package-xyz
%end
</pre>

'''Note:''' all packages that depend on the package you want to remove should be removed also, otherwise MIC2 will ignore your request and keep that package in the image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it will include both of these pgks in the image.

=== Post scripts ===

You can also specify post-scripts to be run after the image is created.

''Example:''
<pre>
%post
# Example - saving some space
rm -f /boot/initrd*
rm -f /core*

# Example - Install working xorg.conf
if [ -f /usr/share/my.conf ]; then
cp /usr/share/my.conf /etc/X11/xorg.conf
fi

# Example - Tell alsa the correct audio card to use for your platform
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
robe.d/alsa.conf
%end
</pre>

== Generate .ks file from Kickstarter ==
It's strongly recommended to create .ks files by kickstarter from image-configurations.

=== image-configuration ===
You can get image-configurations noarch package here: http://download.meego.com/live/Trunk/standard/noarch/

The package of image-configurations also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=image-configurations&project=Trunk
The organization of image-configurations:

configuration.yaml -- default and platform generic configs, also point to external platform path, it's the entrance for kickstart.
repos.yaml -- a list of repositories to be used in the kickstart files
core -- path for image-configs under 'core' platform
compliance -- path for image-configs under 'compliance' platform
ivi -- path for image-configs under 'ivi' platform
handset -- path for image-configs under 'handset' platform
netbook -- path for image-configs under 'netbook' platform
tablet -- path for image-configs under 'tablet' platform
custom/part -- store partition definition
custom/scripts -- store postscripts definition

=== Kickstarter ===
Kickstarter is a tool for create kickstart files to build meego images.

You can download it here: http://repo.meego.com/MeeGo/tools/repos/meego/trunk/noarch/

This tool is also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=kickstarter&project=Trunk

Example:
kickstarter --configs configurations.yaml --repos repos.yaml

Configuration file:
The "configuration.yaml" file here is an example only, for meego kickstart files, please get from the image-configurations package.

This file has the definition of configurations. The Configurations inherit from platforms first then from the DEFAULT section. The image configurations override the all other settings (in DEFAULT and platform sections).

Repo file:
This file contains a list of repositories to be used in the kickstart files.

== Kickstart from image-configurations ==

It's strongly recommended to create .ks files by kickstarter from image-configurations.

You can get image-configurations noarch package here: http://download.meego.com/live/Trunk/standard/noarch/

The package of image-configurations also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=image-configurations&project=Trunk

The followings are how does image-configurations manage those parts in .ks files.

This configurations.yaml file has a generic definition of configurations.
The Configurations inherit from platforms first then from the DEFAULT section.
The image configurations override all other settings
(in DEFAULT and platform sections).

Basically all common options should go to the DEFAULT section. If an options is
related to a specific platform, then that option should be added to the platform
section. Try to keep platforms clean and very generic, if needed, create a new
platform section and use it when many options for a new platform are common.

'''''Detail for the keywords'''''

"Name": description of the configuration file
Name: MeeGo Netbook/Nettop

"Schedule": When should this image be generated:
# *: always
# 0: Monday
# 1: Tuesday
# ...
# If no schedule keyword is present, then image will not be created

Schedule: "*"

"Active": if this image is active
Active: True

"Platform": Inherit from platform
Platform: NETBOOK

"Part": Partition specific configs
Part: qemu

# Part are stored in custom/part and referenced by part name

"Kernel": Based kernel
Kernel: kernel-adaptation-mrst

"Architecture": Based architecture
Architecture: ia32

"Mic2Options": MIC2 options to be used when creating this image
Mic2Options: "-f livecd"

"Desktop": Desktop type
Desktop: None

"Timezone"
Timezone: America/New_York

"FileName": The name of the configuration file
FileName: netbook-ia32

"Groups": package groups
Groups:
- MeeGo Netbook Desktop
- MeeGo Core
- Printing
- Games

"ExtraPackages": Additional packages that are not part of any group
ExtraPackages:
- chromium
- adobe-release
- flash-plugin

"Repos": Repos to use in addition to default repos, those are define in the repos.yaml file
Repos:
- adobe

"PostScripts": Post-scripts to be run after the image is installed
PostScripts:
- meegotouch-n900
- bootchart
- fstab-n900
- arch-armv7hl

# post-scripts are stored in custom/scripts and referenced by post-scripts name

Image Configurations - KickStart Files

2011-07-06T13:16:56Z

Kevinwang: /* MeeGo Patterns */

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.

Note that not all KickStart directives and options are supported for creating Meego images. MIC2 also adds some specific directives and options. More explained below

== Official Meego .ks files ==
The official Meego .ks files are here:

Formal release:
http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build:
http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the Meego images you create. Modify these .ks files as you wish to create tailored images.

We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.

== Modify your .ks ==
Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.

You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options

=== Change Partition, Setup and Bootloader options ===
These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc. You can change these depending on what your needs are.
''Example''

<pre>
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
auth --useshadow --enablemd5
part / --size 1500 --ondisk sda --fstype=ext3
rootpw meego
xconfig --startxonboot
bootloader --timeout=0 --append="quiet"
desktop --autologinuser=meego --defaultdesktop=xfce
user --name meego --groups audio,video --password meego
</pre>

=== Specify Repos ===
This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from which to make up your image. You can add official Meego repos, other remote repos, or your own local repos on your dev machine.

''Example''

<pre>
# This is a comment

# My first repo
repo --name=trunk --baseurl=http://mytrunk.myrepo.com

# My second repo
#repo --name=<repo-name-2> --baseurl=< url | local-repo-dir >
</pre>

'''NOTE:''' --name of the repo can be any unique alphanumeric name you give your repo, it can be anything. Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.

To create a repo you can point to on your local developer machine, you can run the following command:

<pre>
createrepo -d <local-dir>
</pre>

Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.

=== Add Packages Groups and Packages ===
* Groups
This specifies exactly what packages will be included in your image. Package groups can be specified with a "@" preceding it, as you can see from the example below:
<pre>
%packages
# Example adding pkg groups
@Core
@X for Netbooks
@Base
@Development Tools
@<my-PkgGroup1>
@<my-PkgGroup2>
</pre>

Package groups are defined in the 'patterns.xml' file, it defines the group names, and what packages are included in each package group, for example:
http://repo.meego.com/MeeGo/releases/1.2.0/repos/oss/ia32/packages/repodata/patterns.xml

The Meego package groups are standard and common for MeeGo image creation. You can define your own package groups in your own non-Meego repos in local, if you are using those.

Please see here for more info in repositories about MeeGo package groups defination:
https://meego.gitorious.org/meego-os-base/package-groups/

* Packages
You can also add individual packages to the image, for example.

<pre>
%packages
# Example adding individual pkgs
kernel-netbook
xorg-x11-server-Xorg-setuid
carrick
xorg-x11-drv-evtouch
<my-pkg-1>
<my-pkg-2>
%end
</pre>

=== How MIC2 picks a package when different versions are available ===
A common question is that, a packageA may has more than one copy with different versions residing in a repo(s) that your .ks is pointing to. How will the MIC2 know which one to pick?

* select the package with highest version number by default
''Example:''

In the repo(s) these are different versions of PackageA: 
PackageA-1.0
PackageA-2.0
PackageA-3.0
MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).

* select the package through "Epoch" version
There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file, such as:
<pre>
Name: <name>
Summary: <summary>
Epoch: 1
Version: <version>
</pre>

MIC2 will first look to compare the 'Epoch' version of the packages. All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.

''Example:'' 
PackageA-1.0 (Epoch not set)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-2.0 in this case. And it follow that:

''Example:'' 
PackageA-1.0 (Epoch=100)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-1.0.

Remember that Meego packages will not have 'Epoch' set, so if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.

=== Remove Packages ===

If you would like to make sure that a pkg should NOT be included, you can specify that with a '-' preceding the package name.

''Example:''
packages 'carrick' and 'package-xyz' will _not_ be included in the image
<pre>
%packages
# Example pkg groups
@Core

# Example adding individual pkgs
kernel-netbook

# Example removing individual pkgs
-carrick
-package-xyz
%end
</pre>

'''Note:''' all packages that depend on the package you want to remove should be removed also, otherwise MIC2 will ignore your request and keep that package in the image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it will include both of these pgks in the image.

=== Post scripts ===

You can also specify post-scripts to be run after the image is created.

''Example:''
<pre>
%post
# Example - saving some space
rm -f /boot/initrd*
rm -f /core*

# Example - Install working xorg.conf
if [ -f /usr/share/my.conf ]; then
cp /usr/share/my.conf /etc/X11/xorg.conf
fi

# Example - Tell alsa the correct audio card to use for your platform
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
robe.d/alsa.conf
%end
</pre>

== Generate .ks file from Kickstarter ==
It's strongly recommended to create .ks files by kickstarter from image-configurations.

=== image-configuration ===
You can get image-configurations noarch package here: http://download.meego.com/live/Trunk/standard/noarch/

The package of image-configurations also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=image-configurations&project=Trunk
The organization of image-configurations:

configuration.yaml -- default and platform generic configs, also point to external platform path, it's the entrance for kickstart.
repos.yaml -- a list of repositories to be used in the kickstart files
core -- path for image-configs under 'core' platform
compliance -- path for image-configs under 'compliance' platform
ivi -- path for image-configs under 'ivi' platform
handset -- path for image-configs under 'handset' platform
netbook -- path for image-configs under 'netbook' platform
tablet -- path for image-configs under 'tablet' platform
custom/part -- store partition definition
custom/scripts -- store postscripts definition

== Kickstarter ==
Kickstarter is a tool for create kickstart files to build meego images.

You can download it here: http://repo.meego.com/MeeGo/tools/repos/meego/trunk/noarch/

This tool is also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=kickstarter&project=Trunk

Example:
kickstarter --configs configurations.yaml --repos repos.yaml

Configuration file:
The "configuration.yaml" file here is an example only, for meego kickstart files,
consult the image-configurations package.

This file has the definition of configurations. The Configurations inherit
from platforms first then from the DEFAULT section. The image configurations
override the all other settings (in DEFAULT and platform sections).

Repo file:
This file contains a list of repositories to be used in the kickstart files.

== Kickstart from image-configurations ==

It's strongly recommended to create .ks files by kickstarter from image-configurations.

You can get image-configurations noarch package here: http://download.meego.com/live/Trunk/standard/noarch/

The package of image-configurations also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=image-configurations&project=Trunk

The followings are how does image-configurations manage those parts in .ks files.

This configurations.yaml file has a generic definition of configurations.
The Configurations inherit from platforms first then from the DEFAULT section.
The image configurations override all other settings
(in DEFAULT and platform sections).

Basically all common options should go to the DEFAULT section. If an options is
related to a specific platform, then that option should be added to the platform
section. Try to keep platforms clean and very generic, if needed, create a new
platform section and use it when many options for a new platform are common.

'''''Detail for the keywords'''''

"Name": description of the configuration file
Name: MeeGo Netbook/Nettop

"Schedule": When should this image be generated:
# *: always
# 0: Monday
# 1: Tuesday
# ...
# If no schedule keyword is present, then image will not be created

Schedule: "*"

"Active": if this image is active
Active: True

"Platform": Inherit from platform
Platform: NETBOOK

"Part": Partition specific configs
Part: qemu

# Part are stored in custom/part and referenced by part name

"Kernel": Based kernel
Kernel: kernel-adaptation-mrst

"Architecture": Based architecture
Architecture: ia32

"Mic2Options": MIC2 options to be used when creating this image
Mic2Options: "-f livecd"

"Desktop": Desktop type
Desktop: None

"Timezone"
Timezone: America/New_York

"FileName": The name of the configuration file
FileName: netbook-ia32

"Groups": package groups
Groups:
- MeeGo Netbook Desktop
- MeeGo Core
- Printing
- Games

"ExtraPackages": Additional packages that are not part of any group
ExtraPackages:
- chromium
- adobe-release
- flash-plugin

"Repos": Repos to use in addition to default repos, those are define in the repos.yaml file
Repos:
- adobe

"PostScripts": Post-scripts to be run after the image is installed
PostScripts:
- meegotouch-n900
- bootchart
- fstab-n900
- arch-armv7hl

# post-scripts are stored in custom/scripts and referenced by post-scripts name

Image Configurations - KickStart Files

2011-07-06T13:10:25Z

Kevinwang: /* Post scripts */

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.

Note that not all KickStart directives and options are supported for creating Meego images. MIC2 also adds some specific directives and options. More explained below

== Official Meego .ks files ==
The official Meego .ks files are here:

Formal release:
http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build:
http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the Meego images you create. Modify these .ks files as you wish to create tailored images.

We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.

== Modify your .ks ==
Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.

You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options

=== Change Partition, Setup and Bootloader options ===
These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc. You can change these depending on what your needs are.
''Example''

<pre>
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
auth --useshadow --enablemd5
part / --size 1500 --ondisk sda --fstype=ext3
rootpw meego
xconfig --startxonboot
bootloader --timeout=0 --append="quiet"
desktop --autologinuser=meego --defaultdesktop=xfce
user --name meego --groups audio,video --password meego
</pre>

=== Specify Repos ===
This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from which to make up your image. You can add official Meego repos, other remote repos, or your own local repos on your dev machine.

''Example''

<pre>
# This is a comment

# My first repo
repo --name=trunk --baseurl=http://mytrunk.myrepo.com

# My second repo
#repo --name=<repo-name-2> --baseurl=< url | local-repo-dir >
</pre>

'''NOTE:''' --name of the repo can be any unique alphanumeric name you give your repo, it can be anything. Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.

To create a repo you can point to on your local developer machine, you can run the following command:

<pre>
createrepo -d <local-dir>
</pre>

Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.

=== Add Packages Groups and Packages ===
* Groups
This specifies exactly what packages will be included in your image. Package groups can be specified with a "@" preceding it, as you can see from the example below:
<pre>
%packages
# Example adding pkg groups
@Core
@X for Netbooks
@Base
@Development Tools
@<my-PkgGroup1>
@<my-PkgGroup2>
</pre>

Package groups are defined in the 'patterns.xml' file, it defines the group names, and what packages are included in each package group, for example:
http://repo.meego.com/MeeGo/releases/1.2.0/repos/oss/ia32/packages/repodata/patterns.xml

The Meego package groups are standard and common for MeeGo image creation. You can define your own package groups in your own non-Meego repos in local, if you are using those.

Please see here for more info in repositories about MeeGo package groups defination:
https://meego.gitorious.org/meego-os-base/package-groups/

* Packages
You can also add individual packages to the image, for example.

<pre>
%packages
# Example adding individual pkgs
kernel-netbook
xorg-x11-server-Xorg-setuid
carrick
xorg-x11-drv-evtouch
<my-pkg-1>
<my-pkg-2>
%end
</pre>

=== How MIC2 picks a package when different versions are available ===
A common question is that, a packageA may has more than one copy with different versions residing in a repo(s) that your .ks is pointing to. How will the MIC2 know which one to pick?

* select the package with highest version number by default
''Example:''

In the repo(s) these are different versions of PackageA: 
PackageA-1.0
PackageA-2.0
PackageA-3.0
MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).

* select the package through "Epoch" version
There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file, such as:
<pre>
Name: <name>
Summary: <summary>
Epoch: 1
Version: <version>
</pre>

MIC2 will first look to compare the 'Epoch' version of the packages. All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.

''Example:'' 
PackageA-1.0 (Epoch not set)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-2.0 in this case. And it follow that:

''Example:'' 
PackageA-1.0 (Epoch=100)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-1.0.

Remember that Meego packages will not have 'Epoch' set, so if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.

=== Remove Packages ===

If you would like to make sure that a pkg should NOT be included, you can specify that with a '-' preceding the package name.

''Example:''
packages 'carrick' and 'package-xyz' will _not_ be included in the image
<pre>
%packages
# Example pkg groups
@Core

# Example adding individual pkgs
kernel-netbook

# Example removing individual pkgs
-carrick
-package-xyz
%end
</pre>

'''Note:''' all packages that depend on the package you want to remove should be removed also, otherwise MIC2 will ignore your request and keep that package in the image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it will include both of these pgks in the image.

=== Post scripts ===

You can also specify post-scripts to be run after the image is created.

''Example:''
<pre>
%post
# Example - saving some space
rm -f /boot/initrd*
rm -f /core*

# Example - Install working xorg.conf
if [ -f /usr/share/my.conf ]; then
cp /usr/share/my.conf /etc/X11/xorg.conf
fi

# Example - Tell alsa the correct audio card to use for your platform
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
robe.d/alsa.conf
%end
</pre>

== MeeGo Patterns ==
MeeGo use image-configurations package to create .ks files with command line tool 'kickstarter'.

The organization of image-configurations:

configuration.yaml -- default and platform generic configs, also point to external platform path, it's the entrance for kickstart.
repos.yaml -- a list of repositories to be used in the kickstart files

core -- path for image-configs under 'core' platform
compliance -- path for image-configs under 'compliance' platform
ivi -- path for image-configs under 'ivi' platform
handset -- path for image-configs under 'handset' platform
netbook -- path for image-configs under 'netbook' platform
tablet -- path for image-configs under 'tablet' platform

custom/part -- store partition definition
custom/scripts -- store postscripts definition

== Kickstarter ==
Kickstarter is a tool for create kickstart files to build meego images.

You can download it here: http://repo.meego.com/MeeGo/tools/repos/meego/trunk/noarch/

This tool is also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=kickstarter&project=Trunk

Example:
kickstarter --configs configurations.yaml --repos repos.yaml

Configuration file:
The "configuration.yaml" file here is an example only, for meego kickstart files,
consult the image-configurations package.

This file has the definition of configurations. The Configurations inherit
from platforms first then from the DEFAULT section. The image configurations
override the all other settings (in DEFAULT and platform sections).

Repo file:
This file contains a list of repositories to be used in the kickstart files.

== Kickstart from image-configurations ==

It's strongly recommended to create .ks files by kickstarter from image-configurations.

You can get image-configurations noarch package here: http://download.meego.com/live/Trunk/standard/noarch/

The package of image-configurations also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=image-configurations&project=Trunk

The followings are how does image-configurations manage those parts in .ks files.

This configurations.yaml file has a generic definition of configurations.
The Configurations inherit from platforms first then from the DEFAULT section.
The image configurations override all other settings
(in DEFAULT and platform sections).

Basically all common options should go to the DEFAULT section. If an options is
related to a specific platform, then that option should be added to the platform
section. Try to keep platforms clean and very generic, if needed, create a new
platform section and use it when many options for a new platform are common.

'''''Detail for the keywords'''''

"Name": description of the configuration file
Name: MeeGo Netbook/Nettop

"Schedule": When should this image be generated:
# *: always
# 0: Monday
# 1: Tuesday
# ...
# If no schedule keyword is present, then image will not be created

Schedule: "*"

"Active": if this image is active
Active: True

"Platform": Inherit from platform
Platform: NETBOOK

"Part": Partition specific configs
Part: qemu

# Part are stored in custom/part and referenced by part name

"Kernel": Based kernel
Kernel: kernel-adaptation-mrst

"Architecture": Based architecture
Architecture: ia32

"Mic2Options": MIC2 options to be used when creating this image
Mic2Options: "-f livecd"

"Desktop": Desktop type
Desktop: None

"Timezone"
Timezone: America/New_York

"FileName": The name of the configuration file
FileName: netbook-ia32

"Groups": package groups
Groups:
- MeeGo Netbook Desktop
- MeeGo Core
- Printing
- Games

"ExtraPackages": Additional packages that are not part of any group
ExtraPackages:
- chromium
- adobe-release
- flash-plugin

"Repos": Repos to use in addition to default repos, those are define in the repos.yaml file
Repos:
- adobe

"PostScripts": Post-scripts to be run after the image is installed
PostScripts:
- meegotouch-n900
- bootchart
- fstab-n900
- arch-armv7hl

# post-scripts are stored in custom/scripts and referenced by post-scripts name

Image Configurations - KickStart Files

2011-07-06T13:07:56Z

Kevinwang: /* Remove Packages */

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.

Note that not all KickStart directives and options are supported for creating Meego images. MIC2 also adds some specific directives and options. More explained below

== Official Meego .ks files ==
The official Meego .ks files are here:

Formal release:
http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build:
http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the Meego images you create. Modify these .ks files as you wish to create tailored images.

We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.

== Modify your .ks ==
Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.

You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options

=== Change Partition, Setup and Bootloader options ===
These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc. You can change these depending on what your needs are.
''Example''

<pre>
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
auth --useshadow --enablemd5
part / --size 1500 --ondisk sda --fstype=ext3
rootpw meego
xconfig --startxonboot
bootloader --timeout=0 --append="quiet"
desktop --autologinuser=meego --defaultdesktop=xfce
user --name meego --groups audio,video --password meego
</pre>

=== Specify Repos ===
This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from which to make up your image. You can add official Meego repos, other remote repos, or your own local repos on your dev machine.

''Example''

<pre>
# This is a comment

# My first repo
repo --name=trunk --baseurl=http://mytrunk.myrepo.com

# My second repo
#repo --name=<repo-name-2> --baseurl=< url | local-repo-dir >
</pre>

'''NOTE:''' --name of the repo can be any unique alphanumeric name you give your repo, it can be anything. Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.

To create a repo you can point to on your local developer machine, you can run the following command:

<pre>
createrepo -d <local-dir>
</pre>

Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.

=== Add Packages Groups and Packages ===
* Groups
This specifies exactly what packages will be included in your image. Package groups can be specified with a "@" preceding it, as you can see from the example below:
<pre>
%packages
# Example adding pkg groups
@Core
@X for Netbooks
@Base
@Development Tools
@<my-PkgGroup1>
@<my-PkgGroup2>
</pre>

Package groups are defined in the 'patterns.xml' file, it defines the group names, and what packages are included in each package group, for example:
http://repo.meego.com/MeeGo/releases/1.2.0/repos/oss/ia32/packages/repodata/patterns.xml

The Meego package groups are standard and common for MeeGo image creation. You can define your own package groups in your own non-Meego repos in local, if you are using those.

Please see here for more info in repositories about MeeGo package groups defination:
https://meego.gitorious.org/meego-os-base/package-groups/

* Packages
You can also add individual packages to the image, for example.

<pre>
%packages
# Example adding individual pkgs
kernel-netbook
xorg-x11-server-Xorg-setuid
carrick
xorg-x11-drv-evtouch
<my-pkg-1>
<my-pkg-2>
%end
</pre>

=== How MIC2 picks a package when different versions are available ===
A common question is that, a packageA may has more than one copy with different versions residing in a repo(s) that your .ks is pointing to. How will the MIC2 know which one to pick?

* select the package with highest version number by default
''Example:''

In the repo(s) these are different versions of PackageA: 
PackageA-1.0
PackageA-2.0
PackageA-3.0
MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).

* select the package through "Epoch" version
There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file, such as:
<pre>
Name: <name>
Summary: <summary>
Epoch: 1
Version: <version>
</pre>

MIC2 will first look to compare the 'Epoch' version of the packages. All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.

''Example:'' 
PackageA-1.0 (Epoch not set)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-2.0 in this case. And it follow that:

''Example:'' 
PackageA-1.0 (Epoch=100)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-1.0.

Remember that Meego packages will not have 'Epoch' set, so if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.

=== Remove Packages ===

If you would like to make sure that a pkg should NOT be included, you can specify that with a '-' preceding the package name.

''Example:''
packages 'carrick' and 'package-xyz' will _not_ be included in the image
<pre>
%packages
# Example pkg groups
@Core

# Example adding individual pkgs
kernel-netbook

# Example removing individual pkgs
-carrick
-package-xyz
%end
</pre>

'''Note:''' all packages that depend on the package you want to remove should be removed also, otherwise MIC2 will ignore your request and keep that package in the image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it will include both of these pgks in the image.

=== Post scripts ===

You can also specify post-scripts to be run after the image is installed.

''Example''
<pre>
%post

# Example - saving some space
rm -f /boot/initrd*
rm -f /core*

# Example - Install working xorg.conf
if [ -f /usr/share/my.conf ]; then
cp /usr/share/my.conf /etc/X11/xorg.conf
fi

# Example - Tell alsa the correct audio card to use for your platform
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
robe.d/alsa.conf

%end
</pre>

== MeeGo Patterns ==
MeeGo use image-configurations package to create .ks files with command line tool 'kickstarter'.

The organization of image-configurations:

configuration.yaml -- default and platform generic configs, also point to external platform path, it's the entrance for kickstart.
repos.yaml -- a list of repositories to be used in the kickstart files

core -- path for image-configs under 'core' platform
compliance -- path for image-configs under 'compliance' platform
ivi -- path for image-configs under 'ivi' platform
handset -- path for image-configs under 'handset' platform
netbook -- path for image-configs under 'netbook' platform
tablet -- path for image-configs under 'tablet' platform

custom/part -- store partition definition
custom/scripts -- store postscripts definition

== Kickstarter ==
Kickstarter is a tool for create kickstart files to build meego images.

You can download it here: http://repo.meego.com/MeeGo/tools/repos/meego/trunk/noarch/

This tool is also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=kickstarter&project=Trunk

Example:
kickstarter --configs configurations.yaml --repos repos.yaml

Configuration file:
The "configuration.yaml" file here is an example only, for meego kickstart files,
consult the image-configurations package.

This file has the definition of configurations. The Configurations inherit
from platforms first then from the DEFAULT section. The image configurations
override the all other settings (in DEFAULT and platform sections).

Repo file:
This file contains a list of repositories to be used in the kickstart files.

== Kickstart from image-configurations ==

It's strongly recommended to create .ks files by kickstarter from image-configurations.

You can get image-configurations noarch package here: http://download.meego.com/live/Trunk/standard/noarch/

The package of image-configurations also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=image-configurations&project=Trunk

The followings are how does image-configurations manage those parts in .ks files.

This configurations.yaml file has a generic definition of configurations.
The Configurations inherit from platforms first then from the DEFAULT section.
The image configurations override all other settings
(in DEFAULT and platform sections).

Basically all common options should go to the DEFAULT section. If an options is
related to a specific platform, then that option should be added to the platform
section. Try to keep platforms clean and very generic, if needed, create a new
platform section and use it when many options for a new platform are common.

'''''Detail for the keywords'''''

"Name": description of the configuration file
Name: MeeGo Netbook/Nettop

"Schedule": When should this image be generated:
# *: always
# 0: Monday
# 1: Tuesday
# ...
# If no schedule keyword is present, then image will not be created

Schedule: "*"

"Active": if this image is active
Active: True

"Platform": Inherit from platform
Platform: NETBOOK

"Part": Partition specific configs
Part: qemu

# Part are stored in custom/part and referenced by part name

"Kernel": Based kernel
Kernel: kernel-adaptation-mrst

"Architecture": Based architecture
Architecture: ia32

"Mic2Options": MIC2 options to be used when creating this image
Mic2Options: "-f livecd"

"Desktop": Desktop type
Desktop: None

"Timezone"
Timezone: America/New_York

"FileName": The name of the configuration file
FileName: netbook-ia32

"Groups": package groups
Groups:
- MeeGo Netbook Desktop
- MeeGo Core
- Printing
- Games

"ExtraPackages": Additional packages that are not part of any group
ExtraPackages:
- chromium
- adobe-release
- flash-plugin

"Repos": Repos to use in addition to default repos, those are define in the repos.yaml file
Repos:
- adobe

"PostScripts": Post-scripts to be run after the image is installed
PostScripts:
- meegotouch-n900
- bootchart
- fstab-n900
- arch-armv7hl

# post-scripts are stored in custom/scripts and referenced by post-scripts name

Image Configurations - KickStart Files

2011-07-06T12:58:21Z

Kevinwang: /* How MIC2 picks a package when different versions are available */

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.

Note that not all KickStart directives and options are supported for creating Meego images. MIC2 also adds some specific directives and options. More explained below

== Official Meego .ks files ==
The official Meego .ks files are here:

Formal release:
http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build:
http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the Meego images you create. Modify these .ks files as you wish to create tailored images.

We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.

== Modify your .ks ==
Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.

You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options

=== Change Partition, Setup and Bootloader options ===
These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc. You can change these depending on what your needs are.
''Example''

<pre>
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
auth --useshadow --enablemd5
part / --size 1500 --ondisk sda --fstype=ext3
rootpw meego
xconfig --startxonboot
bootloader --timeout=0 --append="quiet"
desktop --autologinuser=meego --defaultdesktop=xfce
user --name meego --groups audio,video --password meego
</pre>

=== Specify Repos ===
This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from which to make up your image. You can add official Meego repos, other remote repos, or your own local repos on your dev machine.

''Example''

<pre>
# This is a comment

# My first repo
repo --name=trunk --baseurl=http://mytrunk.myrepo.com

# My second repo
#repo --name=<repo-name-2> --baseurl=< url | local-repo-dir >
</pre>

'''NOTE:''' --name of the repo can be any unique alphanumeric name you give your repo, it can be anything. Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.

To create a repo you can point to on your local developer machine, you can run the following command:

<pre>
createrepo -d <local-dir>
</pre>

Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.

=== Add Packages Groups and Packages ===
* Groups
This specifies exactly what packages will be included in your image. Package groups can be specified with a "@" preceding it, as you can see from the example below:
<pre>
%packages
# Example adding pkg groups
@Core
@X for Netbooks
@Base
@Development Tools
@<my-PkgGroup1>
@<my-PkgGroup2>
</pre>

Package groups are defined in the 'patterns.xml' file, it defines the group names, and what packages are included in each package group, for example:
http://repo.meego.com/MeeGo/releases/1.2.0/repos/oss/ia32/packages/repodata/patterns.xml

The Meego package groups are standard and common for MeeGo image creation. You can define your own package groups in your own non-Meego repos in local, if you are using those.

Please see here for more info in repositories about MeeGo package groups defination:
https://meego.gitorious.org/meego-os-base/package-groups/

* Packages
You can also add individual packages to the image, for example.

<pre>
%packages
# Example adding individual pkgs
kernel-netbook
xorg-x11-server-Xorg-setuid
carrick
xorg-x11-drv-evtouch
<my-pkg-1>
<my-pkg-2>
%end
</pre>

=== How MIC2 picks a package when different versions are available ===
A common question is that, a packageA may has more than one copy with different versions residing in a repo(s) that your .ks is pointing to. How will the MIC2 know which one to pick?

* select the package with highest version number by default
''Example:''

In the repo(s) these are different versions of PackageA: 
PackageA-1.0
PackageA-2.0
PackageA-3.0
MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).

* select the package through "Epoch" version
There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file, such as:
<pre>
Name: <name>
Summary: <summary>
Epoch: 1
Version: <version>
</pre>

MIC2 will first look to compare the 'Epoch' version of the packages. All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.

''Example:'' 
PackageA-1.0 (Epoch not set)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-2.0 in this case. And it follow that:

''Example:'' 
PackageA-1.0 (Epoch=100)
PackageA-2.0 (Epoch = 1)
PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-1.0.

Remember that Meego packages will not have 'Epoch' set, so if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.

=== Remove Packages ===

If you would like to make sure that a pkg is _not_ included, you can specify that with a '-' preceding the package name.

''Example''
<pre>
%packages

# Example pkg groups

@Core

# Example adding individual pkgs

kernel-netbook

# Example removing individual pkgs

-carrick
-package-xyz

%end
</pre>

with the above example, packages 'carrick' and 'package-xyz' will _not_ be included in the image.

'''Note:''' all packages that depend on the package you want to remove should also be removed, or else MIC2 will ignore your request to remove that package from an image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it includes both of these pgks in the image.

=== Post scripts ===

You can also specify post-scripts to be run after the image is installed.

''Example''
<pre>
%post

# Example - saving some space
rm -f /boot/initrd*
rm -f /core*

# Example - Install working xorg.conf
if [ -f /usr/share/my.conf ]; then
cp /usr/share/my.conf /etc/X11/xorg.conf
fi

# Example - Tell alsa the correct audio card to use for your platform
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
robe.d/alsa.conf

%end
</pre>

== MeeGo Patterns ==
MeeGo use image-configurations package to create .ks files with command line tool 'kickstarter'.

The organization of image-configurations:

configuration.yaml -- default and platform generic configs, also point to external platform path, it's the entrance for kickstart.
repos.yaml -- a list of repositories to be used in the kickstart files

core -- path for image-configs under 'core' platform
compliance -- path for image-configs under 'compliance' platform
ivi -- path for image-configs under 'ivi' platform
handset -- path for image-configs under 'handset' platform
netbook -- path for image-configs under 'netbook' platform
tablet -- path for image-configs under 'tablet' platform

custom/part -- store partition definition
custom/scripts -- store postscripts definition

== Kickstarter ==
Kickstarter is a tool for create kickstart files to build meego images.

You can download it here: http://repo.meego.com/MeeGo/tools/repos/meego/trunk/noarch/

This tool is also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=kickstarter&project=Trunk

Example:
kickstarter --configs configurations.yaml --repos repos.yaml

Configuration file:
The "configuration.yaml" file here is an example only, for meego kickstart files,
consult the image-configurations package.

This file has the definition of configurations. The Configurations inherit
from platforms first then from the DEFAULT section. The image configurations
override the all other settings (in DEFAULT and platform sections).

Repo file:
This file contains a list of repositories to be used in the kickstart files.

== Kickstart from image-configurations ==

It's strongly recommended to create .ks files by kickstarter from image-configurations.

You can get image-configurations noarch package here: http://download.meego.com/live/Trunk/standard/noarch/

The package of image-configurations also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=image-configurations&project=Trunk

The followings are how does image-configurations manage those parts in .ks files.

This configurations.yaml file has a generic definition of configurations.
The Configurations inherit from platforms first then from the DEFAULT section.
The image configurations override all other settings
(in DEFAULT and platform sections).

Basically all common options should go to the DEFAULT section. If an options is
related to a specific platform, then that option should be added to the platform
section. Try to keep platforms clean and very generic, if needed, create a new
platform section and use it when many options for a new platform are common.

'''''Detail for the keywords'''''

"Name": description of the configuration file
Name: MeeGo Netbook/Nettop

"Schedule": When should this image be generated:
# *: always
# 0: Monday
# 1: Tuesday
# ...
# If no schedule keyword is present, then image will not be created

Schedule: "*"

"Active": if this image is active
Active: True

"Platform": Inherit from platform
Platform: NETBOOK

"Part": Partition specific configs
Part: qemu

# Part are stored in custom/part and referenced by part name

"Kernel": Based kernel
Kernel: kernel-adaptation-mrst

"Architecture": Based architecture
Architecture: ia32

"Mic2Options": MIC2 options to be used when creating this image
Mic2Options: "-f livecd"

"Desktop": Desktop type
Desktop: None

"Timezone"
Timezone: America/New_York

"FileName": The name of the configuration file
FileName: netbook-ia32

"Groups": package groups
Groups:
- MeeGo Netbook Desktop
- MeeGo Core
- Printing
- Games

"ExtraPackages": Additional packages that are not part of any group
ExtraPackages:
- chromium
- adobe-release
- flash-plugin

"Repos": Repos to use in addition to default repos, those are define in the repos.yaml file
Repos:
- adobe

"PostScripts": Post-scripts to be run after the image is installed
PostScripts:
- meegotouch-n900
- bootchart
- fstab-n900
- arch-armv7hl

# post-scripts are stored in custom/scripts and referenced by post-scripts name

Image Configurations - KickStart Files

2011-07-06T12:41:27Z

Kevinwang: /* Add Packages and Package Groups */

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.

Note that not all KickStart directives and options are supported for creating Meego images. MIC2 also adds some specific directives and options. More explained below

== Official Meego .ks files ==
The official Meego .ks files are here:

Formal release:
http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build:
http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the Meego images you create. Modify these .ks files as you wish to create tailored images.

We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.

== Modify your .ks ==
Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.

You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options

=== Change Partition, Setup and Bootloader options ===
These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc. You can change these depending on what your needs are.
''Example''

<pre>
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
auth --useshadow --enablemd5
part / --size 1500 --ondisk sda --fstype=ext3
rootpw meego
xconfig --startxonboot
bootloader --timeout=0 --append="quiet"
desktop --autologinuser=meego --defaultdesktop=xfce
user --name meego --groups audio,video --password meego
</pre>

=== Specify Repos ===
This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from which to make up your image. You can add official Meego repos, other remote repos, or your own local repos on your dev machine.

''Example''

<pre>
# This is a comment

# My first repo
repo --name=trunk --baseurl=http://mytrunk.myrepo.com

# My second repo
#repo --name=<repo-name-2> --baseurl=< url | local-repo-dir >
</pre>

'''NOTE:''' --name of the repo can be any unique alphanumeric name you give your repo, it can be anything. Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.

To create a repo you can point to on your local developer machine, you can run the following command:

<pre>
createrepo -d <local-dir>
</pre>

Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.

=== Add Packages Groups and Packages ===
* Groups
This specifies exactly what packages will be included in your image. Package groups can be specified with a "@" preceding it, as you can see from the example below:
<pre>
%packages
# Example adding pkg groups
@Core
@X for Netbooks
@Base
@Development Tools
@<my-PkgGroup1>
@<my-PkgGroup2>
</pre>

Package groups are defined in the 'patterns.xml' file, it defines the group names, and what packages are included in each package group, for example:
http://repo.meego.com/MeeGo/releases/1.2.0/repos/oss/ia32/packages/repodata/patterns.xml

The Meego package groups are standard and common for MeeGo image creation. You can define your own package groups in your own non-Meego repos in local, if you are using those.

Please see here for more info in repositories about MeeGo package groups defination:
https://meego.gitorious.org/meego-os-base/package-groups/

* Packages
You can also add individual packages to the image, for example.

<pre>
%packages
# Example adding individual pkgs
kernel-netbook
xorg-x11-server-Xorg-setuid
carrick
xorg-x11-drv-evtouch
<my-pkg-1>
<my-pkg-2>
%end
</pre>

=== How MIC2 picks a package when different versions are available ===

A common problem is that, let's say, a packageA has more than one version residing in a repo(s) that your .ks is pointing to.

How will the MIC2 know which one to pick?

''Example''

There exists in the repo(s) these different versions of PackageA:

PackageA-1.0

PackageA-2.0

PackageA-3.0

MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).

There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file.

<pre>
Example (works in both .spec and .yaml file)

Name: <name>
Summary: <summary>
Epoch: 1
Version: <version>

</pre>

MIC2 will first look to compare the 'Epoch' version of the packages. All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.

So back to our example.

''Example''

PackageA-1.0 (Epoch not set)

PackageA-2.0 (Epoch = 1)

PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-2.0 in this case. And it follow that:

''Example''

PackageA-1.0 (Epoch=100)

PackageA-2.0 (Epoch = 1)

PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-1.0.

Remember that Meego packages will not have 'Epoch' set, so chances are that if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.

=== Remove Packages ===

If you would like to make sure that a pkg is _not_ included, you can specify that with a '-' preceding the package name.

''Example''
<pre>
%packages

# Example pkg groups

@Core

# Example adding individual pkgs

kernel-netbook

# Example removing individual pkgs

-carrick
-package-xyz

%end
</pre>

with the above example, packages 'carrick' and 'package-xyz' will _not_ be included in the image.

'''Note:''' all packages that depend on the package you want to remove should also be removed, or else MIC2 will ignore your request to remove that package from an image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it includes both of these pgks in the image.

=== Post scripts ===

You can also specify post-scripts to be run after the image is installed.

''Example''
<pre>
%post

# Example - saving some space
rm -f /boot/initrd*
rm -f /core*

# Example - Install working xorg.conf
if [ -f /usr/share/my.conf ]; then
cp /usr/share/my.conf /etc/X11/xorg.conf
fi

# Example - Tell alsa the correct audio card to use for your platform
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
robe.d/alsa.conf

%end
</pre>

== MeeGo Patterns ==
MeeGo use image-configurations package to create .ks files with command line tool 'kickstarter'.

The organization of image-configurations:

configuration.yaml -- default and platform generic configs, also point to external platform path, it's the entrance for kickstart.
repos.yaml -- a list of repositories to be used in the kickstart files

core -- path for image-configs under 'core' platform
compliance -- path for image-configs under 'compliance' platform
ivi -- path for image-configs under 'ivi' platform
handset -- path for image-configs under 'handset' platform
netbook -- path for image-configs under 'netbook' platform
tablet -- path for image-configs under 'tablet' platform

custom/part -- store partition definition
custom/scripts -- store postscripts definition

== Kickstarter ==
Kickstarter is a tool for create kickstart files to build meego images.

You can download it here: http://repo.meego.com/MeeGo/tools/repos/meego/trunk/noarch/

This tool is also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=kickstarter&project=Trunk

Example:
kickstarter --configs configurations.yaml --repos repos.yaml

Configuration file:
The "configuration.yaml" file here is an example only, for meego kickstart files,
consult the image-configurations package.

This file has the definition of configurations. The Configurations inherit
from platforms first then from the DEFAULT section. The image configurations
override the all other settings (in DEFAULT and platform sections).

Repo file:
This file contains a list of repositories to be used in the kickstart files.

== Kickstart from image-configurations ==

It's strongly recommended to create .ks files by kickstarter from image-configurations.

You can get image-configurations noarch package here: http://download.meego.com/live/Trunk/standard/noarch/

The package of image-configurations also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=image-configurations&project=Trunk

The followings are how does image-configurations manage those parts in .ks files.

This configurations.yaml file has a generic definition of configurations.
The Configurations inherit from platforms first then from the DEFAULT section.
The image configurations override all other settings
(in DEFAULT and platform sections).

Basically all common options should go to the DEFAULT section. If an options is
related to a specific platform, then that option should be added to the platform
section. Try to keep platforms clean and very generic, if needed, create a new
platform section and use it when many options for a new platform are common.

'''''Detail for the keywords'''''

"Name": description of the configuration file
Name: MeeGo Netbook/Nettop

"Schedule": When should this image be generated:
# *: always
# 0: Monday
# 1: Tuesday
# ...
# If no schedule keyword is present, then image will not be created

Schedule: "*"

"Active": if this image is active
Active: True

"Platform": Inherit from platform
Platform: NETBOOK

"Part": Partition specific configs
Part: qemu

# Part are stored in custom/part and referenced by part name

"Kernel": Based kernel
Kernel: kernel-adaptation-mrst

"Architecture": Based architecture
Architecture: ia32

"Mic2Options": MIC2 options to be used when creating this image
Mic2Options: "-f livecd"

"Desktop": Desktop type
Desktop: None

"Timezone"
Timezone: America/New_York

"FileName": The name of the configuration file
FileName: netbook-ia32

"Groups": package groups
Groups:
- MeeGo Netbook Desktop
- MeeGo Core
- Printing
- Games

"ExtraPackages": Additional packages that are not part of any group
ExtraPackages:
- chromium
- adobe-release
- flash-plugin

"Repos": Repos to use in addition to default repos, those are define in the repos.yaml file
Repos:
- adobe

"PostScripts": Post-scripts to be run after the image is installed
PostScripts:
- meegotouch-n900
- bootchart
- fstab-n900
- arch-armv7hl

# post-scripts are stored in custom/scripts and referenced by post-scripts name

Distribution

2011-07-06T12:22:35Z

Kevinwang: /* Distribution Infrastructure */

This page describes basic information you needed if you want to contribute to MeeGo. Target audience is community member who wish to involve in MeeGo development.

== Package Management and Development ==
=== Overview ===
Like other Linux distros, MeeGo is a package-based system, and it is using [http://www.rpm.org/max-rpm/index.html RPM] package end. The RPM packages are managed in [http://wiki.meego.com/Zypper Zypper] repos. The MeeGo development is done by using the upstream project [http://wiki.opensuse.org/Portal:Build_Service Open Build Service (OBS)]. If you are a serious and frequent MeeGo contributor, you need an OBS account to commit your changes back to MeeGo. Other casual contributors can work without using OBS, but you need a MeeGo development team member to help review and commit your changes into MeeGo.

The process of develop with an OBS account:
Branch, Check-out, Make changes, Deployment the new package and test, Make a new image (optional), Submit your changes.

The process of develop without using OBS:
Download MeeGo from a repo, build a chroot env, get the source of a package, make changes, build and test the new package, how to debug the local build, find a MeeGo team member to sponsor your changes and submit them back.

* [[Distribution/Package_Management|Package Management]]

=== Development with MeeGo OBS account ===
* [[Build_Infrastructure/Packagers_Developers#How_to_get_started|Request a new OBS account]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_1|Login and first steps]]
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_2|Link packages and adding a repository]]
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_commandline_client|How to use the command line client for daily operations]]
* [[Build_Infrastructure/Packagers_Developers/Using_OBS_chroot_for_development|Using OBS chroot for development]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]
* [[Build_Infrastructure/Packagers_Developers#Troubleshooting|Troubleshooting]]

=== Development without MeeGo OBS account ===
* [[Local_Build_Without_OBS_Needed|Build and develop packages without OBS ]]
* [[Recompile_kernel | Example: Recompile kernel]]
* [[How to development with multiple packages with dependencies]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]

=== Packaging ===
* [[Packaging/Guidelines|Packaging Guidelines]]

=== Process ===
* [[Release_Engineering/New_Package_Checklist|Checklist for new package submissions]]
* [[Release_Engineering/Submission_Checklist|Developer's checklist for code submissions]]
* [[Build_Infrastructure/Packagers_Developers#IRC_.2F_mailinglists_.2F_contact|irc / mailing lists / contact]]

== Developer Tools ==
=== Image Creation ===
* [[Image_Creation|MIC2]]
* [[Image_Creation_For_Beginners|MIC2 for Beginners]]
* [[Image Configurations - KickStart Files]]

=== OBS command line ===
* Part 1 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_1|initial setup]]
* Part 2 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|checkout & branch]]
* Part 3 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_4|more commands: localcheckbuild]]

=== Spec tool ===
* [[Spectacle|Spectacle]]

== Distribution Infrastructure ==
* [[Build_Infrastructure|Build Infrastructure - OBS]]
* [[Release_Infrastructure/BOSS|Release Infrastructure - BOSS]]

== Software Repo ==
* [[Create and update repos]]

== Links ==
* [[Release_Engineering|Release Engineering]]
* [[Quality/Compliance|Compliance]]
* [[Quality|Quality]]

Image Configurations - KickStart Files

2011-07-06T10:15:46Z

Kevinwang: /* Modify your .ks */

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.

Note that not all KickStart directives and options are supported for creating Meego images. MIC2 also adds some specific directives and options. More explained below

== Official Meego .ks files ==
The official Meego .ks files are here:

Formal release:
http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build:
http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the Meego images you create. Modify these .ks files as you wish to create tailored images.

We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.

== Modify your .ks ==
Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.

You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options

=== Change Partition, Setup and Bootloader options ===
These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc. You can change these depending on what your needs are.
''Example''

<pre>
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
auth --useshadow --enablemd5
part / --size 1500 --ondisk sda --fstype=ext3
rootpw meego
xconfig --startxonboot
bootloader --timeout=0 --append="quiet"
desktop --autologinuser=meego --defaultdesktop=xfce
user --name meego --groups audio,video --password meego
</pre>

=== Specify Repos ===
This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from which to make up your image. You can add official Meego repos, other remote repos, or your own local repos on your dev machine.

''Example''

<pre>
# This is a comment

# My first repo
repo --name=trunk --baseurl=http://mytrunk.myrepo.com

# My second repo
#repo --name=<repo-name-2> --baseurl=< url | local-repo-dir >
</pre>

'''NOTE:''' --name of the repo can be any unique alphanumeric name you give your repo, it can be anything. Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.

To create a repo you can point to on your local developer machine, you can run the following command:

<pre>
createrepo -d <local-dir>
</pre>

Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.

=== Add Packages and Package Groups ===
This specifies exactly what packages will be included in your image. Package groups can be specified with a "@" preceding it, as you can see from the examples above. Package groups are defined in the 'repodata' section of a repo, under a 'comps*.xml' file. Defined therein are package group names, and what packages are included in each package group. The Meego package groups are standard, and cannot be changed. You can, however, define your own package groups in your own non-Meego repos, if you are using those.

Please see here for more info on defining package groups in repositories: TO-DO-LINK

You can also add individual package names to be included in the image as you can see from the second part in the example.

''Example''

<pre>
%packages

# Example adding pkg groups

@Core
@X for Netbooks
@Base
@Development Tools
@<my-PkgGroup1>
@<my-PkgGroup2>

# Example adding individual pkgs

kernel-netbook
xorg-x11-server-Xorg-setuid
carrick
xorg-x11-drv-evtouch
<my-pkg-1>
<my-pkg-2>
%end

</pre>

=== How MIC2 picks a package when different versions are available ===

A common problem is that, let's say, a packageA has more than one version residing in a repo(s) that your .ks is pointing to.

How will the MIC2 know which one to pick?

''Example''

There exists in the repo(s) these different versions of PackageA:

PackageA-1.0

PackageA-2.0

PackageA-3.0

MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).

There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file.

<pre>
Example (works in both .spec and .yaml file)

Name: <name>
Summary: <summary>
Epoch: 1
Version: <version>

</pre>

MIC2 will first look to compare the 'Epoch' version of the packages. All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.

So back to our example.

''Example''

PackageA-1.0 (Epoch not set)

PackageA-2.0 (Epoch = 1)

PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-2.0 in this case. And it follow that:

''Example''

PackageA-1.0 (Epoch=100)

PackageA-2.0 (Epoch = 1)

PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-1.0.

Remember that Meego packages will not have 'Epoch' set, so chances are that if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.

=== Remove Packages ===

If you would like to make sure that a pkg is _not_ included, you can specify that with a '-' preceding the package name.

''Example''
<pre>
%packages

# Example pkg groups

@Core

# Example adding individual pkgs

kernel-netbook

# Example removing individual pkgs

-carrick
-package-xyz

%end
</pre>

with the above example, packages 'carrick' and 'package-xyz' will _not_ be included in the image.

'''Note:''' all packages that depend on the package you want to remove should also be removed, or else MIC2 will ignore your request to remove that package from an image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it includes both of these pgks in the image.

=== Post scripts ===

You can also specify post-scripts to be run after the image is installed.

''Example''
<pre>
%post

# Example - saving some space
rm -f /boot/initrd*
rm -f /core*

# Example - Install working xorg.conf
if [ -f /usr/share/my.conf ]; then
cp /usr/share/my.conf /etc/X11/xorg.conf
fi

# Example - Tell alsa the correct audio card to use for your platform
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
robe.d/alsa.conf

%end
</pre>

== MeeGo Patterns ==
MeeGo use image-configurations package to create .ks files with command line tool 'kickstarter'.

The organization of image-configurations:

configuration.yaml -- default and platform generic configs, also point to external platform path, it's the entrance for kickstart.
repos.yaml -- a list of repositories to be used in the kickstart files

core -- path for image-configs under 'core' platform
compliance -- path for image-configs under 'compliance' platform
ivi -- path for image-configs under 'ivi' platform
handset -- path for image-configs under 'handset' platform
netbook -- path for image-configs under 'netbook' platform
tablet -- path for image-configs under 'tablet' platform

custom/part -- store partition definition
custom/scripts -- store postscripts definition

== Kickstarter ==
Kickstarter is a tool for create kickstart files to build meego images

Example:
kickstarter --configs configurations.yaml --repos repos.yaml

Configuration file:
The "configuration.yaml" file here is an example only, for meego kickstart files,
consult the image-configurations package.

This file has the definition of configurations. The Configurations inherit
from platforms first then from the DEFAULT section. The image configurations
override the all other settings (in DEFAULT and platform sections).

Repo file:
This file contains a list of repositories to be used in the kickstart files.

== Kickstart from image-configurations ==

It's strongly recommended to create .ks files by kickstarter from image-configurations.
The followings are how does image-configurations manage those parts in .ks files.

This configurations.yaml file has a generic definition of configurations.
The Configurations inherit from platforms first then from the DEFAULT section.
The image configurations override all other settings
(in DEFAULT and platform sections).

Basically all common options should go to the DEFAULT section. If an options is
related to a specific platform, then that option should be added to the platform
section. Try to keep platforms clean and very generic, if needed, create a new
platform section and use it when many options for a new platform are common.

'''''Detail for the keywords'''''

"Name": description of the configuration file
Name: MeeGo Netbook/Nettop

"Schedule": When should this image be generated:
# *: always
# 0: Monday
# 1: Tuesday
# ...
# If no schedule keyword is present, then image will not be created

Schedule: "*"

"Active": if this image is active
Active: True

"Platform": Inherit from platform
Platform: NETBOOK

"Part": Partition specific configs
Part: qemu

# Part are stored in custom/part and referenced by part name

"Kernel": Based kernel
Kernel: kernel-adaptation-mrst

"Architecture": Based architecture
Architecture: ia32

"Mic2Options": MIC2 options to be used when creating this image
Mic2Options: "-f livecd"

"Desktop": Desktop type
Desktop: None

"Timezone"
Timezone: America/New_York

"FileName": The name of the configuration file
FileName: netbook-ia32

"Groups": package groups
Groups:
- MeeGo Netbook Desktop
- MeeGo Core
- Printing
- Games

"ExtraPackages": Additional packages that are not part of any group
ExtraPackages:
- chromium
- adobe-release
- flash-plugin

"Repos": Repos to use in addition to default repos, those are define in the repos.yaml file
Repos:
- adobe

"PostScripts": Post-scripts to be run after the image is installed
PostScripts:
- meegotouch-n900
- bootchart
- fstab-n900
- arch-armv7hl

# post-scripts are stored in custom/scripts and referenced by post-scripts name

Image Configurations - KickStart Files

2011-07-06T09:30:02Z

Kevinwang: /* MeeGo Patterns */

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.

Note that not all KickStart directives and options are supported for creating Meego images. MIC2 also adds some specific directives and options. More explained below

== Official Meego .ks files ==
The official Meego .ks files are here:

Formal release:
http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build:
http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the Meego images you create. Modify these .ks files as you wish to create tailored images.

We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.

== Modify your .ks ==
Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.

You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options

'''''Partition, Setup and Bootloader options'''''

''Example''

<pre>
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
auth --useshadow --enablemd5
part / --size 1500 --ondisk sda --fstype=ext3
rootpw meego
xconfig --startxonboot
bootloader --timeout=0 --append="quiet"
desktop --autologinuser=meego --defaultdesktop=xfce
user --name meego --groups audio,video --password meego
</pre>

These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc. You can change these depending on what your needs are.

'''''Repos'''''

This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from which to make up your image. You can add official Meego repos, other remote repos, or your own local repos on your dev machine.

''Example''

<pre>
# This is a comment

# My first repo
repo --name=trunk --baseurl=http://mytrunk.myrepo.com

# My second repo
#repo --name=<repo-name-2> --baseurl=< url | local-repo-dir >
</pre>

'''NOTE:''' --name of the repo can be any unique alphanumeric name you give your repo, it can be anything. Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.

To create a repo you can point to on your local developer machine, you can run the following command:

<pre>
createrepo -d <local-dir>
</pre>

Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.

'''''Adding Packages and Package Groups'''''

''Example''

<pre>
%packages

# Example adding pkg groups

@Core
@X for Netbooks
@Base
@Development Tools
@<my-PkgGroup1>
@<my-PkgGroup2>

# Example adding individual pkgs

kernel-netbook
xorg-x11-server-Xorg-setuid
carrick
xorg-x11-drv-evtouch
<my-pkg-1>
<my-pkg-2>
%end

</pre>

This specifies exactly what packages will be included in your image. Package groups can be specified with a "@" preceding it, as you can see from the examples above. Package groups are defined in the 'repodata' section of a repo, under a 'comps*.xml' file. Defined therein are package group names, and what packages are included in each package group. The Meego package groups are standard, and cannot be changed. You can, however, define your own package groups in your own non-Meego repos, if you are using those.

Please see here for more info on defining package groups in repositories: TO-DO-LINK

You can also add individual package names to be included in the image as you can see from the second part in the above example.

'''''Important Note about how MIC2 picks a package when different versions are available'''''

A common problem is that, let's say, a packageA has more than one version residing in a repo(s) that your .ks is pointing to.

How will the MIC2 know which one to pick?

''Example''

There exists in the repo(s) these different versions of PackageA:

PackageA-1.0

PackageA-2.0

PackageA-3.0

MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).

There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file.

<pre>
Example (works in both .spec and .yaml file)

Name: <name>
Summary: <summary>
Epoch: 1
Version: <version>

</pre>

MIC2 will first look to compare the 'Epoch' version of the packages. All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.

So back to our example.

''Example''

PackageA-1.0 (Epoch not set)

PackageA-2.0 (Epoch = 1)

PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-2.0 in this case. And it follow that:

''Example''

PackageA-1.0 (Epoch=100)

PackageA-2.0 (Epoch = 1)

PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-1.0.

Remember that Meego packages will not have 'Epoch' set, so chances are that if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.

'''''Removing Packages'''''

If you would like to make sure that a pkg is _not_ included, you can specify that with a '-' preceding the package name.

''Example''
<pre>
%packages

# Example pkg groups

@Core

# Example adding individual pkgs

kernel-netbook

# Example removing individual pkgs

-carrick
-package-xyz

%end
</pre>

with the above example, packages 'carrick' and 'package-xyz' will _not_ be included in the image.

'''Note:''' all packages that depend on the package you want to remove should also be removed, or else MIC2 will ignore your request to remove that package from an image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it includes both of these pgks in the image.

'''''Post scripts'''''

You can also specify post-scripts to be run after the image is installed.

''Example''
<pre>
%post

# Example - saving some space
rm -f /boot/initrd*
rm -f /core*

# Example - Install working xorg.conf
if [ -f /usr/share/my.conf ]; then
cp /usr/share/my.conf /etc/X11/xorg.conf
fi

# Example - Tell alsa the correct audio card to use for your platform
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
robe.d/alsa.conf

%end
</pre>

== MeeGo Patterns ==
MeeGo use image-configurations package to create .ks files with command line tool 'kickstarter'.

The organization of image-configurations:

configuration.yaml -- default and platform generic configs, also point to external platform path, it's the entrance for kickstart.
repos.yaml -- a list of repositories to be used in the kickstart files

core -- path for image-configs under 'core' platform
compliance -- path for image-configs under 'compliance' platform
ivi -- path for image-configs under 'ivi' platform
handset -- path for image-configs under 'handset' platform
netbook -- path for image-configs under 'netbook' platform
tablet -- path for image-configs under 'tablet' platform

custom/part -- store partition definition
custom/scripts -- store postscripts definition

== Kickstarter ==
Kickstarter is a tool for create kickstart files to build meego images

Example:
kickstarter --configs configurations.yaml --repos repos.yaml

Configuration file:
The "configuration.yaml" file here is an example only, for meego kickstart files,
consult the image-configurations package.

This file has the definition of configurations. The Configurations inherit
from platforms first then from the DEFAULT section. The image configurations
override the all other settings (in DEFAULT and platform sections).

Repo file:
This file contains a list of repositories to be used in the kickstart files.

== Kickstart from image-configurations ==

It's strongly recommended to create .ks files by kickstarter from image-configurations.
The followings are how does image-configurations manage those parts in .ks files.

This configurations.yaml file has a generic definition of configurations.
The Configurations inherit from platforms first then from the DEFAULT section.
The image configurations override all other settings
(in DEFAULT and platform sections).

Basically all common options should go to the DEFAULT section. If an options is
related to a specific platform, then that option should be added to the platform
section. Try to keep platforms clean and very generic, if needed, create a new
platform section and use it when many options for a new platform are common.

'''''Detail for the keywords'''''

"Name": description of the configuration file
Name: MeeGo Netbook/Nettop

"Schedule": When should this image be generated:
# *: always
# 0: Monday
# 1: Tuesday
# ...
# If no schedule keyword is present, then image will not be created

Schedule: "*"

"Active": if this image is active
Active: True

"Platform": Inherit from platform
Platform: NETBOOK

"Part": Partition specific configs
Part: qemu

# Part are stored in custom/part and referenced by part name

"Kernel": Based kernel
Kernel: kernel-adaptation-mrst

"Architecture": Based architecture
Architecture: ia32

"Mic2Options": MIC2 options to be used when creating this image
Mic2Options: "-f livecd"

"Desktop": Desktop type
Desktop: None

"Timezone"
Timezone: America/New_York

"FileName": The name of the configuration file
FileName: netbook-ia32

"Groups": package groups
Groups:
- MeeGo Netbook Desktop
- MeeGo Core
- Printing
- Games

"ExtraPackages": Additional packages that are not part of any group
ExtraPackages:
- chromium
- adobe-release
- flash-plugin

"Repos": Repos to use in addition to default repos, those are define in the repos.yaml file
Repos:
- adobe

"PostScripts": Post-scripts to be run after the image is installed
PostScripts:
- meegotouch-n900
- bootchart
- fstab-n900
- arch-armv7hl

# post-scripts are stored in custom/scripts and referenced by post-scripts name

Image Configurations - KickStart Files

2011-07-06T09:29:24Z

Kevinwang: /* Modify your .ks */

Image Configurations - KickStart Files

2011-07-06T09:27:50Z

Kevinwang: /* Official Meego .ks files */

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.

Note that not all KickStart directives and options are supported for creating Meego images. MIC2 also adds some specific directives and options. More explained below

== Official Meego .ks files ==
The official Meego .ks files are here:

Formal release:
http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build:
http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the Meego images you create. Modify these .ks files as you wish to create tailored images.

We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.

== MeeGo Patterns ==
MeeGo use image-configurations package to create .ks files with command line tool 'kickstarter'.

The organization of image-configurations:

configuration.yaml -- default and platform generic configs, also point to external platform path, it's the entrance for kickstart.
repos.yaml -- a list of repositories to be used in the kickstart files

core -- path for image-configs under 'core' platform
compliance -- path for image-configs under 'compliance' platform
ivi -- path for image-configs under 'ivi' platform
handset -- path for image-configs under 'handset' platform
netbook -- path for image-configs under 'netbook' platform
tablet -- path for image-configs under 'tablet' platform

custom/part -- store partition definition
custom/scripts -- store postscripts definition

== Kickstarter ==
Kickstarter is a tool for create kickstart files to build meego images

Example:
kickstarter --configs configurations.yaml --repos repos.yaml

Configuration file:
The "configuration.yaml" file here is an example only, for meego kickstart files,
consult the image-configurations package.

This file has the definition of configurations. The Configurations inherit
from platforms first then from the DEFAULT section. The image configurations
override the all other settings (in DEFAULT and platform sections).

Repo file:
This file contains a list of repositories to be used in the kickstart files.

== Modify your .ks ==
Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.

You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options

'''''Partition, Setup and Bootloader options'''''

''Example''

<pre>
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
auth --useshadow --enablemd5
part / --size 1500 --ondisk sda --fstype=ext3
rootpw meego
xconfig --startxonboot
bootloader --timeout=0 --append="quiet"
desktop --autologinuser=meego --defaultdesktop=xfce
user --name meego --groups audio,video --password meego
</pre>

These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc. You can change these depending on what your needs are.

'''''Repos'''''

This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from which to make up your image. You can add official Meego repos, other remote repos, or your own local repos on your dev machine.

''Example''

<pre>
# This is a comment

# My first repo
repo --name=trunk --baseurl=http://mytrunk.myrepo.com

# My second repo
#repo --name=<repo-name-2> --baseurl=< url | local-repo-dir >
</pre>

'''NOTE:''' --name of the repo can be any unique alphanumeric name you give your repo, it can be anything. Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.

To create a repo you can point to on your local developer machine, you can run the following command:

<pre>
createrepo -d <local-dir>
</pre>

Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.

'''''Adding Packages and Package Groups'''''

''Example''

<pre>
%packages

# Example adding pkg groups

@Core
@X for Netbooks
@Base
@Development Tools
@<my-PkgGroup1>
@<my-PkgGroup2>

# Example adding individual pkgs

kernel-netbook
xorg-x11-server-Xorg-setuid
carrick
xorg-x11-drv-evtouch
<my-pkg-1>
<my-pkg-2>
%end

</pre>

This specifies exactly what packages will be included in your image. Package groups can be specified with a "@" preceding it, as you can see from the examples above. Package groups are defined in the 'repodata' section of a repo, under a 'comps*.xml' file. Defined therein are package group names, and what packages are included in each package group. The Meego package groups are standard, and cannot be changed. You can, however, define your own package groups in your own non-Meego repos, if you are using those.

Please see here for more info on defining package groups in repositories: TO-DO-LINK

You can also add individual package names to be included in the image as you can see from the second part in the above example.

'''''Important Note about how MIC2 picks a package when different versions are available'''''

A common problem is that, let's say, a packageA has more than one version residing in a repo(s) that your .ks is pointing to.

How will the MIC2 know which one to pick?

''Example''

There exists in the repo(s) these different versions of PackageA:

PackageA-1.0

PackageA-2.0

PackageA-3.0

MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).

There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file.

<pre>
Example (works in both .spec and .yaml file)

Name: <name>
Summary: <summary>
Epoch: 1
Version: <version>

</pre>

MIC2 will first look to compare the 'Epoch' version of the packages. All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.

So back to our example.

''Example''

PackageA-1.0 (Epoch not set)

PackageA-2.0 (Epoch = 1)

PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-2.0 in this case. And it follow that:

''Example''

PackageA-1.0 (Epoch=100)

PackageA-2.0 (Epoch = 1)

PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-1.0.

Remember that Meego packages will not have 'Epoch' set, so chances are that if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.

'''''Removing Packages'''''

If you would like to make sure that a pkg is _not_ included, you can specify that with a '-' preceding the package name.

''Example''
<pre>
%packages

# Example pkg groups

@Core

# Example adding individual pkgs

kernel-netbook

# Example removing individual pkgs

-carrick
-package-xyz

%end
</pre>

with the above example, packages 'carrick' and 'package-xyz' will _not_ be included in the image.

'''Note:''' all packages that depend on the package you want to remove should also be removed, or else MIC2 will ignore your request to remove that package from an image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it includes both of these pgks in the image.

'''''Post scripts'''''

You can also specify post-scripts to be run after the image is installed.

''Example''
<pre>
%post

# Example - saving some space
rm -f /boot/initrd*
rm -f /core*

# Example - Install working xorg.conf
if [ -f /usr/share/my.conf ]; then
cp /usr/share/my.conf /etc/X11/xorg.conf
fi

# Example - Tell alsa the correct audio card to use for your platform
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
robe.d/alsa.conf

%end
</pre>

== Kickstart from image-configurations ==

It's strongly recommended to create .ks files by kickstarter from image-configurations.
The followings are how does image-configurations manage those parts in .ks files.

This configurations.yaml file has a generic definition of configurations.
The Configurations inherit from platforms first then from the DEFAULT section.
The image configurations override all other settings
(in DEFAULT and platform sections).

Basically all common options should go to the DEFAULT section. If an options is
related to a specific platform, then that option should be added to the platform
section. Try to keep platforms clean and very generic, if needed, create a new
platform section and use it when many options for a new platform are common.

'''''Detail for the keywords'''''

"Name": description of the configuration file
Name: MeeGo Netbook/Nettop

"Schedule": When should this image be generated:
# *: always
# 0: Monday
# 1: Tuesday
# ...
# If no schedule keyword is present, then image will not be created

Schedule: "*"

"Active": if this image is active
Active: True

"Platform": Inherit from platform
Platform: NETBOOK

"Part": Partition specific configs
Part: qemu

# Part are stored in custom/part and referenced by part name

"Kernel": Based kernel
Kernel: kernel-adaptation-mrst

"Architecture": Based architecture
Architecture: ia32

"Mic2Options": MIC2 options to be used when creating this image
Mic2Options: "-f livecd"

"Desktop": Desktop type
Desktop: None

"Timezone"
Timezone: America/New_York

"FileName": The name of the configuration file
FileName: netbook-ia32

"Groups": package groups
Groups:
- MeeGo Netbook Desktop
- MeeGo Core
- Printing
- Games

"ExtraPackages": Additional packages that are not part of any group
ExtraPackages:
- chromium
- adobe-release
- flash-plugin

"Repos": Repos to use in addition to default repos, those are define in the repos.yaml file
Repos:
- adobe

"PostScripts": Post-scripts to be run after the image is installed
PostScripts:
- meegotouch-n900
- bootchart
- fstab-n900
- arch-armv7hl

# post-scripts are stored in custom/scripts and referenced by post-scripts name

2011-07-04T06:01:38Z

Kevinwang: /* OBS & Repos & Package */

== Development ==
=== Basic ===
* [[rpm and repos]]
* [[OBS basic]]
* [[Create and update repos]]
* [[Distribution/Package_Management|Package Management]]

=== Development with MeeGo OBS account ===
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_webinterface|How to use the web interface to view, manage and build your packages.]]
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_commandline_client|How to use the command line client for daily operations]]
* [[Build_Infrastructure/Packagers_Developers/Using_OBS_chroot_for_development|Using OBS chroot for development]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]
* [[Build_Infrastructure/Packagers_Developers#Troubleshooting|Troubleshooting]]

=== Development without MeeGo OBS account ===
* [[Local_Build_Without_OBS_Needed|Build and develop packages without OBS ]]
* [[Recompile_kernel | Example: Recompile kernel]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]

=== Packaging ===
* [[Packaging/Guidelines|Packaging Guidelines]]
* [[SDK/Docs/1.0/Packaging/Tutorial|Application Packaging Tutorial]]

=== Process ===
* [[Build_Infrastructure/Packagers_Developers#How_to_get_started|Request a new OBS account]]
* [[Create new package in OBS]]
* [[Remove package from OBS]]
* [[Commit changes to OBS]]
* [[Build_Infrastructure/Packagers_Developers#IRC_.2F_mailinglists_.2F_contact|irc / mailing lists / contact]]

== Developer Tools ==
=== Image Creation ===
* [[Image_Creation|MIC2]]
* [[Image_Creation_For_Beginners|MIC2 for Beginners]]
* [[Image Configurations & KS files]]

=== OBS command line ===
* Part 1 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_1|initial setup]]
* Part 2 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|checkout & branch]]
* Part 3 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_4|more commands: localcheckbuild]]

=== Spec tool ===
* [[Spectacle|Spectacle]]

== Distribution Infrastructure ==
* [[Build_Infrastructure|Build Infrastructure - OBS]]
* [[Release Infrastructure - BOSS]]

== Links ==
* [[Release_Engineering|Release Engineering]]
* [[Quality/Compliance|Compliance]]
* [[Quality|Quality]]

Distribution

2011-07-04T05:44:36Z

Kevinwang: /* Packaging */

== Development ==
=== OBS & Repos & Package===
* [[OBS basic]]
* [[repos and released images]]
* [[Create and update repos]]
* [[Distribution/Package_Management|Package Management]]

=== Development with MeeGo OBS account ===
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_webinterface|How to use the web interface to view, manage and build your packages.]]
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_commandline_client|How to use the command line client for daily operations]]
* [[Build_Infrastructure/Packagers_Developers/Using_OBS_chroot_for_development|Using OBS chroot for development]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]
* [[Build_Infrastructure/Packagers_Developers#Troubleshooting|Troubleshooting]]

=== Development without MeeGo OBS account ===
* [[Local_Build_Without_OBS_Needed|Build and develop packages without OBS ]]
* [[Recompile_kernel | Example: Recompile kernel]]
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]

=== Packaging ===
* [[Packaging/Guidelines|Packaging Guidelines]]
* [[SDK/Docs/1.0/Packaging/Tutorial|Application Packaging Tutorial]]

=== Process ===
* [[Build_Infrastructure/Packagers_Developers#How_to_get_started|Request a new OBS account]]
* [[Create new package in OBS]]
* [[Remove package from OBS]]
* [[Commit changes to OBS]]
* [[Build_Infrastructure/Packagers_Developers#IRC_.2F_mailinglists_.2F_contact|irc / mailing lists / contact]]

== Developer Tools ==
=== Image Creation ===
* [[Image_Creation|MIC2]]
* [[Image_Creation_For_Beginners|MIC2 for Beginners]]
* [[Image Configurations & KS files]]

=== OBS command line ===
* Part 1 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_1|initial setup]]
* Part 2 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|checkout & branch]]
* Part 3 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_4|more commands: localcheckbuild]]

=== Spec tool ===
* [[Spectacle|Spectacle]]

== Distribution Infrastructure ==
* [[Build_Infrastructure|Build Infrastructure - OBS]]
* [[Release Infrastructure - BOSS]]

== Links ==
* [[Release_Engineering|Release Engineering]]
* [[Quality/Compliance|Compliance]]
* [[Quality|Quality]]