MeeGo wiki - User contributions [en]

Packaging/Guidelines

2011-06-01T04:20:51Z

Gabrbedd: Add info about post-install scripts.

= Packaging Guidelines =

Guidelines below were adapted for MeeGo from Moblin, OpenSUSE, Fedora and other distributions.

== Maintaining a Package ==
Every package in MeeGo needs a maintainer (AKA owner, bug owner). Any package without an owner will automatically be nominated for deletion from MeeGo. A package maintainer is responsible for making sure that
* packages are up to date with latest upstream
* packages consistently build in the MeeGo build system and fix build failures when they occur
* package meta data in the RPM spec file is accurate
* the license of the package is correct
* she/he follow upstream for any critical security issues and fix them ASAP
* she/he Provides information about major changes to other packagers and maintainer to allow enough time for fixing compatibility issues

Since the data about ownership of packages is not maintained anywhere right now we are starting to use available meta data fields in the build system to track ownership. This will be better integrated and managed at a later point, but to be able to start somewhere MeeGo will use the bugowner key available for every package. We will start adding the metadata about maintainers (bugowners) in the build system and we will have agrace period for this data to be supplied and added to the build system. After the grace period, packages without maintainer will be reviewed and any packages without a maintainer will be nominated for deletion.

To add yourself as a bugowner of a package, please follow the steps below:
* Update to the most recent osc version (0.130) from the MeeGo tools repository. Note: this is essential, since the needed options are not released upstream yet. Tools: http://repo.meego.com/MeeGo/tools/repos/
* Identify the packages of which you are the ultimate maintainer
* Do the following for every package you maintain in the Trunk:* projects:
<code>
osc reqms --role bugowner <project> <package> -m "I want to own this because I love this package"
</code>
* Your request will be sent and someone in release engineering will approve it

The current status can be seen here: [[Packaging/Maintainers]]

== Package Naming ==
* Dash '-' must be used as the delimiter for name parts.
* Do NOT use an underscore '_', a plus '+', or a period '.' as a delimiter.
* The spec file should be named using the %{name}.spec scheme which should also correspond to the package name within a project in the build system.

== Version and Release ==

Package Versions look like : X.Y.Z-R.B
* X.Y.Z is the 'Version' number - determined by the source package.
* R is the 'Release' number which is automatically incremented by OBS whenever a source/packaging changes (eg a check-in or request acceptance)
* B is the build number which is incremented when the package is rebuilt due to a dependency change.

=== Version ===

The Version field in the spec file is where you should put the current version of the software being packaged.
There are four cases where the version contains non-numeric characters:

* Pre-release packages: Packages released as "pre-release" versions, prior to a "final" version. Example tags include "alpha", "beta", "rc", "cvs", "git", "svn", etc... Details can be found below: Non-Numeric Version.
* Post-release packages: Packages released after a "final" version. These packages contain the same numeric version as the "final" version, but have an additional non-numeric identifier. This mechanism may also be used for packaging only changes to an upstream package.
* Snapshot packages: Packages built from SCM snapshots. These packages could be either "pre" or "post" release packages.

==== Non-Numeric Version ====

We can use letters and tilde into the version tag. We do not use the Release field for this.

Example:
<pre>
Let's assume the following Qt versions:
Qt 4.7.0~beta1
Qt 4.7.0~beta1+git1
Qt 4.7.0~beta2
Qt 4.7.0

Version comparison results:
$ rpmdev-vercmp 4.7.0~beta1 4.7.0~beta1+git1
0:4.7.0~beta1+git1-None is newer

$ rpmdev-vercmp 4.7.0~beta1+git2 4.7.0~beta2
0:4.7.0~beta2-None is newer

$ rpmdev-vercmp 4.7.0~beta2 4.7.0
0:4.7.0-None is newer

Conclusion:
4.7.0~beta1 < 4.7.0~beta1+git1 < 4.7.0~beta2 < 4.7.0
</pre>

Note that the ~ comparison order is specific to MeeGo rpm (http://rpm.org/ticket/56).

=== Release ===

This field is handled by the build system to be able to manage automated builds. The initial setting in the spec file is used by the build system but in many cases it does not need to be changed.

There is no need for the %{dist} macro in the release field. This is also handled directly by the build system.

The release number is set to zero with any version update. It is increased by one with any change in the package.

We can put letters into the version tag, so we do not use the Release field for this. Details can be found above.

If you build the package outside of the OBS or if you copy a package then you will of course not get the correct Release or Build values.

== Tags ==
*The ''Packager'' tag should not be used in spec files. The identities of the packagers are evident from the changelog entries. By not using the ''Packager'' tag, you also avoid seeing bad binaries rebuilt by someone else with your name in the header. See also the '''Maximum RPM definition of the Packager tag''' at [http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html#S3-RPM-INSIDE-PACKAGER-TAG www.rpm.org] . If you need to include information about the packager in the rpms ''you'' built, use <code>%packager</code> in your <code>~/.rpmmacros</code> instead.
*The ''Vendor'' tag should not be used. It is set automatically by the build system.

*Usually, the ''Pre<code></code>Req'' tag should be replaced by plain ''Requires''. For more info, see Maximum RPM snapshot's [http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-FINE-GRAINED fine grained dependencies chapter] .
* The ''Source'' tag documents where to find the upstream sources for the rpm. In most cases this should be a complete URL to the upstream tarball.
=== Summary Tag ===
The summary is a single line string describing the package. The maximum length is 80 characters. It should fit all standard situations and not assume any special context. It should be helpful alone, in alphabetically sorted or unsorted lists of some selected packages, and in alphabetically sorted or unsorted lists of all packages.

It should describe the package's main function and point out any special properties of the package to support the user comparing similar packages. For example, the two words "Web Browser" summarize any web browser, but using additional adjectives (like minimalistic, complex, GNOME, KDE, text-based, fast, or author's) helps characterize a specific package.

The RPM spec file contains only the English version to keep the RPM database small.

*The ''Summary'' tag value should not end in a period. If this bothers you from a grammatical point of view, sit down, take a deep breath, and get over it.

=== Group Tag ===

Valid RPM Groups are:
<pre>
Amusements/Games
Amusements/Graphics
Applications/Archiving
Applications/Communications
Applications/Databases
Applications/Editors
Applications/Emulators
Applications/Engineering
Applications/File
Applications/Internet
Applications/Multimedia
Applications/Productivity
Applications/Publishing
Applications/System
Applications/Text
Development/Debuggers
Development/Languages
Development/Libraries
Development/System
Development/Tools
Documentation
System/Boot
System/Console
System/I18n/Chinese
System/I18n/Japanese
System/I18n/Korean
System/Packages
System/Base
System/Daemons
System/Kernel
System/Libraries
System/Shells
System/X11
System/X11/Fonts
System/X11/Icons
System/GUI/XFCE
System/GUI/Other
System/GUI/GNOME
</pre>

==== Domain/Subsystem based RPM Groups ====

Following the new architecture and the new [http://meego.com/developers/meego-architecture/meego-architecture-domain-view domain view], RPM groups (The Group tag in the RPM) for core packages will be changed to match the domains and any package in the core that is part of one of the domain will have a corresponding group that matches the architecture.

{|
! Domain
! Subsystem
!Groupname
|-
| Communications || Cellular Adaptation || Communications/Cellular Adaptation
|-
| Communications || Cellular Framework || Communications/Cellular Framework
|-
| Communications || Telephony and IM || Communications/Telephony and IM
|-
| Communications || Bluetooth || Communications/Bluetooth
|-
| Communications || Connectivity Adaptation || Communications/Connectivity Adaptation
|-
| Communications || ConnMan || Communications/ConnMan
|-
| Data Management || Content Framework || Data Management/Content Framework
|-
| Development Platform || Platform SDK || Development Platform/Platform SDK
|-
| Essentials || Base Essentials || Essentials/Base Essentials
|-
| Graphics || Font Management || Graphics/Font Management
|-
| Graphics || Display and Graphics Adaptation || Graphics/Display and Graphics Adaptation
|-
| Graphics || Input Adaptation || Graphics/Input Adaptation
|-
| Graphics || Open GL ES || Graphics/Open GL ES
|-
| Graphics || X11 || Graphics/X11
|-
| Kernel || Linux Kernel || Kernel/Linux Kernel
|-
| Location || Location Framework || Location/Location Framework
|-
| Location || Location Adaptation || Location/Location Adaptation
|-
| Multimedia || Audio Adaptation || Multimedia/Audio Adaptation
|-
| Multimedia || Camera Adaptation || Multimedia/Camera Adaptation
|-
| Multimedia || Gstreamer || Multimedia/Gstreamer
|-
| Multimedia || Imaging and Video Adaptation || Multimedia/Imaging and Video Adaptation
|-
| Multimedia || Imaging Codecs || Multimedia/Imaging Codecs
|-
| Multimedia || PulseAudio || Multimedia/PulseAudio
|-
| Multimedia || Sharing || Multimedia/Sharing
|-
| Multimedia || UPnP || Multimedia/UPnP
|-
| Personal Information Management || Backup Framework || Personal Information Management/Backup Framework
|-
| Personal Information Management || Calendar Engine || Personal Information Management/Calendar Engine
|-
| Personal Information Management || Contacts Engine || Personal Information Management/Contacts Engine
|-
| Personal Information Management || Email Engine || Personal Information Management/Email Engine
|-
| Personal Information Management || Synchronization Framework || Personal Information Management/Synchronization Framework
|-
| Qt || Qt || Qt/Qt
|-
| Qt || Qt Mobility || Qt/Qt Mobility
|-
| Qt || Qt WebKit || Qt/Qt WebKit
|-
| Security || Accounts || Security/Accounts
|-
| Security || Certificate Manager || Security/Certificate Manager
|-
| Security || Integrity Protection Framework || Security/Integrity Protection Framework
|-
| Security || Access Control Framework || Security/Access Control Framework
|-
| Security || Single Sign-On || Security/Single Sign-On
|-
| Security || SW Distribution Security || Security/SW Distribution Security
|-
| Security || Security Adaptation || Security/Security Adaptation
|-
| Software Management || Package Manager || Software Management/Package Manager
|-
| System || Context Framework || System/Context Framework
|-
| System || NGF || System/NGF
|-
| System || Resource Policy || System/Resource Policy
|-
| System || Sensor Adaptation || System/Sensor Adaptation
|-
| System || Sensor Framework || System/Sensor Framework
|-
| System || Startup Services || System/Startup Services
|-
| System || System Control || System/System Control
|-
| System || Device Mode Adaptation || System/Device Mode Adaptation
|-
| System || Vibra and Haptics Adaptation || System/Vibra and Haptics Adaptation
|-

|}

=== BuildRoot tag ===
The ''BuildRoot'' value MUST be below <code>%{_tmppath}/</code> and MUST contain at least <code>%{name}</code>, <code>%{version}</code> and <code>%{release}</code>.

The ''recommended'' values for the ''BuildRoot'' tag are (in descending order of preference) :
<pre>
%{_tmppath}/%{name}-%{version}-%{release}-root
</pre>

The BuildRoot tag can be omitted in packages targeting MeeGo only and is handled directly by rpm in MeeGo, for packages that need to run on other distros with older rpm it should be added for backward compatibility.

=== PreReq ===

Packages should not use the PreReq tag. Once upon a time, in dependency loops PreReq used to "win" over the conventional Requires when RPM determined the installation order in a transaction. This is no longer the case.

=== Explicit Requires ===
Packages must not contain explicit ''Requires'' on libraries except when absolutely
necessary. When explicit library ''Requires'' are necessary, there should be a spec file comment justifying it.

We generally rely on rpmbuild to automatically add dependencies on library SONAMEs.
Modern package management tools are capable of resolving such dependencies to determine
the required packages. Explicit dependencies on specific package names may aid the
inexperienced user, who attempts at installing RPM packages manually, however, history
has shown that such dependencies add confusion when library/files are moved from one
package to another, when packages get renamed, when one out of multiple alternative
packages would suffice, and when versioned explicit dependencies become out-of-date and
inaccurate. Additionally, in some cases, old explicit dependencies on package names
require unnecessary updates/rebuilds.

Exemplary rationale for a versioned explicit dependency:
<pre>
# The automatic dependency on libfubar.so.1 is insufficient,
# as we strictly need at least the release that fixes two segfaults.
Requires: libfubar >= 0:1.2.3-7
</pre>

Packagers should revisit an explicit dependency as appropriate to avoid
it becoming inaccurate and superfluous.

=== BuildRequires ===

In package development and testing, please verify that your package is not missing any necessary build dependencies. Having proper build requirements saves the time of all developers and testers as well as build systems because they will not need to search for missing build requirements manually. It is also a safety feature that prevents builds with that would not otherwise fail, but would be missing crucial features. For example, a graphical application may exclude PNG support after its '''configure''' script detects that libpng is not installed.

Before adding Build<code></code>Requires to any package, please be comfortable with [[#Requires| Requires]] .

=== Patches ===
Each problem should be solved in a separate patch. To allow easy maintenance of patches, every patch should have a header providing the following information:

* Authors' names
* [http://meego.com/about/contribution-guidelines/signed-process Signed-off-by] tag
* Detailed description of the fixed problem
* URL of the original source of the patch if any

The name of a patch file consists of:

* The name and version of the source tarball from which the patched file is derived
* Some words that characterize the patch content
* The filename suffix <code class="filename">.patch</code>

Patches are in the unified format ('''diff -u''') and should be applied with 1 strip level in the spec file ('''%patch -p1'''). The only exceptions are the patches obtained from an another primary source site. The original name, suffix, and format is preserved in this case.

Each patch should be compressed with '''bzip2''' if its size is greater than 100kB. The macros <code class="systemitem">%name</code> and <code class="systemitem">%version</code> should be used whenever possible.

Example:

Source: %{name}-%{version}.tar.bz2
Patch0: %{name}-%{version}-autoconf.patch
Patch1: %{name}-%{version}-gcc31.patch

For the patches to be applied, the patches should be mentioned under %setup. For the above example, this could be done as

%setup -q
%patch0 -p1
%patch1 -p1

Patches have to be marked as such in the spec file and should be applied using the internal patch routines available in rpm. Use of alternate patch management system not supported by rpm is not allowed.

=== %clean ===

The %clean section is not required for MeeGo 1.1 and above. Each package for MeeGo 1.0 MUST have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).

== Documentation ==
Any relevant documentation included in the source distribution should be included in the package. Irrelevant documentation include build instructions, the omnipresent ''INSTALL'' file containing generic build instructions, for example, and documentation for non-Linux systems, e.g. ''README.MSDOS''. Pay also attention about which subpackage you include documentation in, for example API documentation belongs in the -devel subpackage, not the main one. Or if there's a lot of documentation, consider putting it into a subpackage. In this case, it is recommended to use <code>*-doc</code> as the subpackage name, and <code>Documentation</code> as the value of the <code>Group</code> tag.

Also, if a package includes something as <code>%doc</code>, it must not affect the runtime of the application. To summarize: If it is in <code>%doc</code>, the program must run properly if it is not present.

== Devel Packages ==
If the software being packaged contains files intended solely for development, those files should be put in a -devel subpackage. The following are examples of file types which should be in -devel:
* Header files (such as .h files)
* Unversioned shared libraries (such as libfoo.so). Versioned shared libraries (such as libfoo.so.3, libfoo.so.3.0.0) should not be in -devel.

A good rule of thumb is if the file is used for development and not needed for the base package to run properly, it should go in -devel.

=== Requiring Base Package ===
Devel packages must require the base package using a fully versioned dependency: <code>Requires: %{name} = %{version}-%{release}</code>.
Usually, subpackages other than -devel should also require the base package using a fully versioned dependency.

=== Pkgconfig Files ===
The placement of pkgconfig(.pc) files depends on their usecase. Since they are almost always used for development purposes, they should be placed in a -devel package.
A reasonable exception is when the main package itself is a development tool not installed in a user runtime, such as gcc or gdb.

== Test Packages ==
Tests should be included in -test subpackage or separate package according to the following guidelines.

[http://wiki.meego.com/Test_Packaging Test Packaging Guidelines]

== Shared Libraries ==
Whenever possible (and feasible), MeeGo Packages containing libraries should build them as shared libraries. In addition, every binary RPM package which contains shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in <code>%post</code> and <code>%postun</code>. If the package has multiple subpackages with libraries, each subpackage should also have a <code>%post/%postun</code> section that calls <code>/sbin/ldconfig</code>. An example of the correct syntax for this is:
<pre>
%post -p /sbin/ldconfig

%postun -p /sbin/ldconfig
</pre>
Note that this specific syntax only works if <code>/sbin/ldconfig</code> is the only call in <code>%post</code> and <code>%postun</code>. If you have additional commands to run during the scriptlet, call <code>/sbin/ldconfig</code> at the beginning of the scriptlet, like this:
<pre>
%post
/sbin/ldconfig
/usr/bin/foo --add

%postun
/sbin/ldconfig
/usr/bin/foo --remove
</pre>

== Configuration files ==

Configuration files must be marked as such in packages.

As a rule of thumb, use <code>%config(noreplace)</code> instead of plain <code>%config</code> unless your best, educated guess is that doing so will break things. In other words, think hard before overwriting local changes in configuration files on package upgrades. An example case when /not/ to use <code>noreplace</code> is when a package's configuration file changes so that the new package revision wouldn't work with the config file from the previous package revision. Whenever plain <code>%config</code> is used, add a brief comment to the specfile explaining why.

Don't use %config or %config(noreplace) under /usr. /usr is deemed to not contain configuration files in MeeGo.

== Initscripts ==

Currently, only SystemV-style initscripts are supported in MeeGo.

== Desktop files ==

If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window. Installed .desktop files MUST follow the [http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html desktop-entry-spec] , paying particular attention to validating correct usage of Name, GenericName, [http://standards.freedesktop.org/menu-spec/latest/apa.html Categories] ,
[http://www.freedesktop.org/Standards/startup-notification-spec StartupNotify]
entries.

=== Icon tag in Desktop Files ===
The icon tag can be specified in two ways:

* Full path to specific icon file:
<code> Icon=/usr/share/pixmaps/comical.png </code>

* Short name without file extension:
<code> Icon=comical </code>

The short name without file extension is preferred, because it allows for icon theming (it assumes .png by default, then tries .svg and finally .xpm), but either method is acceptable.

=== .desktop file creation ===
If the package doesn't already include and install its own .desktop file, you need to make your own. You can do this by including a .desktop file you create as a Source: (such as Source3: %{name}.desktop) or generating it in the spec file. Here are the contents of a sample .desktop file (comical.desktop):

<pre>
[Desktop Entry]
Name=Comical
GenericName=Comic Archive Reader
Comment=Open .cbr & .cbz files
Exec=comical
Icon=comical
Terminal=false
Type=Application
Categories=Graphics;
</pre>

=== Localizing .desktop files ===
The values of Name or GenericName are displayed as captions to the graphical desktop icon, so they should be localized according to the [http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s04.html Desktop Entry Specification]. Most of the time, only ''language'' codes or ''language/country'' codes are needed to select the intended system locale. For example:

<pre>
[Desktop Entry]
Type=Application
Name=Clocks
Name[de]=Uhrzeit
Name[es]=Relojes
Name[fr]=Horloges
Name[pt_BR]=Relógios
Name[zh_CN]=时钟
Icon=meego-app-clocks
Exec=meego-qml-launcher --opengl --fullscreen --app meego-app-clocks
</pre>

In the above .desktop file, <tt>[de]</tt> specifies the German language locale, covering any German-speaking locale, such as <tt>de_DE</tt> or <tt>de_AT</tt>.

'''Note:''' Since a ''language/country'' code (e.g. <tt>pt_BR</tt>) is more specific than a ''language'' code (e.g. <tt>pt</tt>), a string for the <tt>pt_BR</tt> locale will '''not''' be used for the Portuguese language locale (<tt>pt</tt>). If a string is appropriate for every Portuguese locale, you can use "<tt>Name[pt]</tt>" instead.

=== desktop-file-install usage ===
It is not simply enough to just include the .desktop file in the package, one MUST run <code>desktop-file-install</code> OR <code>desktop-file-validate</code> in <code>%install</code> (and have <code>BuildRequires: desktop-file-utils</code>), to help ensure .desktop file safety and spec-compliance. <code>desktop-file-install</code> MUST be used if the package does not install the file or there are changes desired to the .desktop file (such as add/removing categories, etc). <code>desktop-file-validate</code> MAY be used instead if the .desktop file's content/location does not need modification. Here are some examples of
usage:

<pre>
desktop-file-install \
--dir=${RPM_BUILD_ROOT}%{_datadir}/applications \
%{SOURCE3}
</pre>

<pre>
desktop-file-install \
--add-category="AudioVideo" \
--delete-original \
--dir=%{buildroot}%{_datadir}/applications \
%{buildroot}/%{_datadir}/foo.desktop
</pre>

<pre>
desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop
</pre>

=== .desktop file post-install ===

After installing a .desktop file, it's typical to touch the file and the folder so that the UX will detect the change. Otherwise, the new file will not be detected until reboot. I.e.

%post
touch %{_datadir}/applications/foo.desktop
touch %{_datadir}/applications

...will update the time-stamp of the folder and the .desktop file.

== Macros ==
=== Using %{buildroot} and %{optflags} vs $RPM_BUILD_ROOT and $RPM_OPT_FLAGS ===
There are two styles of defining the rpm Build Root and Optimization Flags in a spec file:

{| border="1"
|-
| ||macro style || variable style
|-
|Build Root||%{buildroot}||$RPM_BUILD_ROOT
|-
|Opt. Flags||%{optflags}||$RPM_OPT_FLAGS
|}

There is very little value in choosing one style over the other, since they will resolve to the same values in all scenarios. You should pick a style and use it consistently throughout your packaging.

Mixing the two styles, while valid, is bad from a QA and usability point of view, and should not be done in MeeGo packages.

== Handling Locale Files ==

If the package includes translations, add
<pre>
BuildRequires: gettext
</pre>
If you don't, your package could fail to generate translation files in the buildroot.

MeeGo includes an rpm macro called <code>%find_lang</code>. This macro will locate all of the locale files that belong to your package (by name), and put this list in a file. You can then use that file to include all of the locales. <code>%find_lang</code> should be run in the %install section of your spec file, after all of the files have been installed into the buildroot. The correct syntax for <code>%find_lang</code> is usually:
<pre>
%find_lang %{name}
</pre>
In some cases, the application may use a different "name" for its locales. You may have to look at the locale files and see what they are named. If they are named <code>myapp.mo</code>, then you will need to pass <code>myapp</code> to <code>%find_lang</code> instead of <code>%{name</code>}.
After <code>%find_lang</code> is run, it will generate a file in the active directory (by default, the top level of the source dir). This file will be named based on what you passed as the option to the <code>%find_lang</code> macro. Usually, it will be named <code>%{name}.lang</code>. You should then use this file in the <code>%files</code> list to include the locales detected by <code>%find_lang</code>. To do this, you should include it with the -f parameter to <code>%files</code>.
<pre>
%files -f %{name}.lang
%defattr(-,root,root,-)
%{_bindir}/foobar
...
</pre>
If you are already using the -f parameter for the <code>%files</code> section where the locales should live, just append the contents of <code>%{name}.lang</code> to the end of the file that you are already using with -f. (Note that only one file may be used with <code>%files -f</code>.)

Here is an example of proper usage of <code>%find_lang</code>, in <code>foo.spec</code>:

<pre>
...
%prep
%setup -q

%build
%configure --with-cheese
make %{?_smp_mflags}

%install
make DESTDIR=%{buildroot} install
%find_lang %{name}

%clean
rm -rf %{buildroot}

%files -f %{name}.lang
%defattr(-,root,root,-)
%doc LICENSE README
%{_bindir}/foobar

</pre>

=== Why do we need to use %find_lang? ===

Using <code>%find_lang</code> helps keep the spec file simple, and helps avoid several other packaging mistakes.

* Packages that use <code>%{_datadir}/*</code> to grab all the locale files in one line also grab ownership of the locale directories, which is not permitted.
* Most packages that have locales have lots of locales. Using <code>%find_lang</code> is much easier in the spec file than having to do:
<pre>
%{_datadir}/locale/ar/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/be/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/cs/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/de/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/es/LC_MESSAGES/%{name}.mo
...
</pre>
* As new locale files appear in later package revisions, <code>%find_lang</code> will automatically include them when it is run, preventing you from having to update the spec any more than is necessary.

Keep in mind that usage of <code>%find_lang</code> in packages containing locales is a MUST.

== Scriptlets ==
Great care should be taken when using scriptlets in MeeGo packages. If scriptlets are used, those scriptlets must be sane.

=== Scriptlets requirements ===
Do not use the <code>Requires(pre,post)</code> style notation for scriptlet dependencies, because of two bugs in RPM. Instead, they should be split like this:
<pre>
Requires(pre): ...
Requires(post): ...
</pre>
For more information, see [http://www.redhat.com/archives/fedora-devel-list/2004-April/msg00674.html www.redhat.com] .

=== Running scriptlets only in certain situations ===
When the rpm command executes the scriptlets in a package it indicates if the action preformed is an install, erase, upgrade or reinstall by passing an integer argument to the script in question according to the following:
<pre>
install erase upgrade reinstall
%pre 1 - 2 2
%post 1 - 2 2
%preun - 0 1 -
%postun - 0 1 -
</pre>
This means that for example a package that installs an init script with the <code>chkconfig</code> command should uninstall it only on erase and not upgrade with the following snippet:
<pre>
%preun
if [ $1 -eq 0 ] ; then
/sbin/chkconfig --del %{name}
fi
</pre>
See also <code>/usr/share/doc/rpm-*/triggers</code>, which gives a more formal, generalized definition about the integer value(s) passed to various scripts.

=== Scriplets are only allowed to write in certain directories ===
Build scripts of packages (%prep, %build, %install, %check and %clean) may only alter files (create, modify, delete) under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process) according to the following matrix

{| border="1"
|-
| || /tmp, /var/tmp, $TMPDIR, %{_tmppath} || %{_builddir} || %{buildroot}
|-
|%prep || yes || yes || no
|-
|%build || yes || yes || no
|-
|%install || yes || yes || yes
|-
|%check || yes || yes || no
|-
|%clean || yes || yes || yes
|}

Further clarification: That should hold true irrespective of the builder's uid.

== Use of Epochs ==
The Epoch tag in RPM is to be used only as a last resort, and should be avoided whenever possible. However, it is sometimes necessary to use an Epoch to handle upstream versioning changes or to ease transition from third party repositories.

== Writing a package from scratch ==

See [[Spectacle]]

Spectacle is a great tool for straightforward packages, and we have many of those, hundreds, many of those packages already have been using spectacle happily for a while now. Generally, the 80/20 rule applies here, almost 80% of packages in MeeGo can be converted to this format, probably around 20% will need to stay as is for various reasons.

Spectacle in general helps a lot when you have a package that does:
* configure
* make
* make install

and especially useful when for example you have to manage many build dependencies and patches or for common packaging of perl/python/X packages that usually follows the same packaging work flow. We have plans to add lots of nice features to make packaging easier and more fun with spectacle.

While spectacle has many advanced options to cover all kind of corner cases, it should not be used for complex packages that would require lots of customization, especially now that we support multiple architectures and where we need to apply code and custom scripts to support different scenarios.

Spectacle provides scripts to convert spec files to spectacle, those try to do their best but you SHOULD never just take the output as is and rely on the script, a review of the output is necessary, otherwise you might end up with lots of duplication in the spec file. This is the most common mistake, developers are relying on the output of the conversion script, basically picking some spec file from another distro and converting it. This can lead to major disasters in some cases.

So to summarize:
* It is NOT mandatory to use spectacle
* If you try to convert and find yourself spending more than a few minutes on a package, then probably there is something wrong and you should not be using that or you should RTFM.
* Use it with care, especially when you first import the data from existing spec files or when you first create your YAML file
* Your distro maintainer might send you a note that certain packages you are maintaining could be converted to spectacle easily, but she/he should not reject your package because it does not use spectacle.
* If you find yourself forced to edit the spec file manually for some reason, then either:
** your package is not suitable to be used with spectacle
** or you might want to ask for a feature to support that special case
* packager should not change packaging format randomly.
** You need to be the main maintainer
** If a package is already using the yaml format, you need to have a valid reason why not to use the yaml format

== Modifying existing Packages ==

If you base a new package on an existing non-MeeGo package, make sure you verify its correctness of the package and the spec file and to understand exactly what has been done to package the software exactly. Do not submit a package without knowing what those strange, but innocent-looking commands do.

In particular, you should

* ensure that original tarballs are self-contained pristine tarballs. The tarball should not contain symlinks that reference outside the tarball root directory
* verify any sources and patches and remove patches or sources that:
** are related to platforms we do not support (example: sparc, ia64, ppc, ...)
** Implement features we do not support (example: selinux)
** Read every patch and understand what it does, if it is needed, put an explanation in the header justifying why the patch is needed.
* verify that the license stated in the spec file matches the actual license of the software,
* skim the summary and description for typos and oddities (see Summary and description ),
* make sure that the correct build root is used,
* ensure that macro usage is consistent and that the macros are available in MeeGo (see Macros ).

Keep old changelog entries to credit the original authors. Entries that are several years old or refer to ancient versions of the software may be erased. If you end up doing radical changes and re-write most of the spec file anyway, feel free to start the changelog from scratch. In other words, use your best judgement.

== Changelogs ==

This section describes the MeeGo policy for RPM changelogs. (Original changelogs included in the original source are not affected by this policy.)

Please consider that a "normal end user with some technical skills" should be able to read and understand an RPM changelog. Changelog entries have to be in reverse chronological order: newer change log entries are listed above older entries, with the first entry being the most recent.

Please bear in mind theat MeeGo changelogs will be automatically parsed to prepare distribution release notes and to report on bugs and CVEs and malformed entries may not be read correctly.

=== General information ===

* MeeGo uses a separate file for package changes which is similar to a debian changelog file. This file is named as the spec file, but ends in *.changes instead of *.spec
* Entries in the changes file should have the following structure:
<pre>
* dow mmm dd yyyy Name Goes Here <your@email.com> - [version]
- comment
- comment

</pre>

Note the following exceptions are noted through observation:
* version is often omitted (such as: alsa-utils 1.0.15-1 -> 1.0.16-1)
* there are multiple changelog entries per version (such as: alsa-utils 1.0.19)
* the hyphen between email and version is often omitted (such as: alsa-utils)
* spaces between name and <email> are omitted (such as: Zhang, Qiang Z<qiang.z.zhang@intel.com> nano)
* name is sometimes omitted (such as: bitstream-vera-fonts nicolas.mailhot at laposte.net)
* <email> is sometimes omitted (such as: binutils Jim Kingdon)
This wide variation in formats makes automation tasks harder than they should be. Please use the correct format.

=== External References ===

Each external reference (bug numbers etc) should be of the form:
"(" + external reference code + bug number +")"

Currently defined:
* MeeGo Bugs : BMC#
* MeeGo Features: FEA#
* Common Vulnerability / Exposure : CVE

==== Bug Numbers in the change log ====

During maintenance of a distribution, every change has to be marked with the correct bug number. Normally this has to be an number from https://bugzilla.meego.com/. Add an entry with bugzilla number and a short description of the bug-summary. For example:
- Removed invalid desktop Category "Application" (BMC#4654).
- Symlink icon to pixmaps dir (BMC#2108)
- Added gnome-ui-properties to control-center (BMC#1960).

New packages related to new features will refer to the corresponding bug number in bugzilla, preceded with an FEA. For example:
- Adding Qt Contacts support FEA#8011

==== CVE numbers in change log ====

As with bug numbers: Add a short description (normally the CVE summary should be enough), the Bugzilla and the CVE number to the changelog entry. Examples:
- Add gdk-pixbuf-226710.patch (BMC#226710), and (CVE-2007-0010).
- More XPM fixes: (CVE-2005-2975) xpm too many colors DoS (BMC#129642)
- fix ~/.dmrc symlink attack (BMC#180704), (CVE-2006-2449)

=== Spec File changes ===
Be as precise as possible! This is especially important if you remove something from the spec file.

* Removing original source code must be declared in spec file with a comment ("useful for FreeBSD only" for example) - not necessary to repeat the comment in specfile.
* Extra commands (for example during %install) can be illustrated with a short comment in spec file
* Adding/Removing packages from Requires/Provides must be described in the changelog

=== Source Code changes ===

Document the most important changes but limit verbosity.

* look into the source changelog and pick up the most important changes for the distribution (changes for other operation systems are not important). What has changed in the new version, usually in the level of detail of a NEWS file, the change log files are usually too long. More than '''10-15 lines''' shouldn't be necessary to describe the most important changes.
* arrange the original changes behind the version update information. Example:
- Update to 1.3.2:
+ fixes memory leak in import function
+ new API command: unlock_client()
+ the following bugs are closed by this new upstream release:
++ ............ [MGN:332]
++ .............[MGN:337]
- split of devel package
* If upstream does not provide a meaningful change log, then only do best effort. Don't waste too much time over it.
* If the upstream tarball really has not changed except for the version number, just the version number in the change log would be fine. Same goes for packages just containing some graphics or theming (unless upstream already provides something that fits). If the upstream changes just consists of "updated translation" or "several bug fixes" even that can be sufficient for a changelog entry (unless these bug fixes contain something you find worth mentioning).

== Packaging Static Libraries ==
Packages including libraries should exclude static libs as far as possible (eg by configuring with ''--disable-static''). Static libraries should only be included in exceptional circumstances. Applications linking against libraries should as far as possible link against shared libraries not static versions.

Libtool archives, ''foo.la'' files, should not be included. Packages using libtool will install these by default even if you configure with ''--disable-static'', so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove *.la files without modifying the program. In most cases it is fairly easy to work with upstream to fix these issues. Note that if you are updating a library in a stable release (not devel) and the package already contains *.la files, removing the *.la files should be treated as an API/ABI change -- ie: Removing them changes the interface that the library gives to the rest of the world and should not be undertaken lightly.

=== Packaging Static Libraries ===
* In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists.

* We want to be able to track which packages are using static libraries (so we can find which packages need to be rebuilt if a security flaw in a static library is fixed, for instance). There are two scenarios in which static libraries are packaged:
# '''Static libraries and shared libraries.''' In this case, the static libraries must be placed in a ''*-static'' subpackage. Separating the static libraries from the other development files in ''*-devel'' allow us to track this usage by checking which packages <code>BuildRequire</code> the ''*-static'' package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries.
# '''Static libraries only.''' When a package only provides static libraries you can place all the static library files in the ''*-devel'' subpackage. When doing this you also must have a virtual Provide for the ''*-static'' package:
<pre>%package devel
Provides: foo-static = %{version}-%{release}</pre>

Packages which explicitly need to link against the static version must <code>BuildRequire: foo-static</code>, so that the usage can be tracked.

* If (and only if) a package has shared libraries which require static libraries to be functional, the static libraries can be included in the ''*-devel'' subpackage. The devel subpackage must have a virtual Provide for the ''*-static'' package, and packages dependent on it must <code>BuildRequire</code> the ''*-static'' package.

=== Staticly Linking Executables ===
* Static linkage is a special exception and should be decided on a case-by-case basis. The packager must provide rationale for linking statically, including precedences where available, to release engineering for approval.

[[Category:Packaging]]

OBS

2011-05-30T22:57:52Z

Gabrbedd: Add clear link to docs

'''Open Build Service (OBS)'''

The OBS (Open Build Service) is a build management system written for the community by openSuse/Novell.

MeeGo has two main OBS setups:
* The [[Core OBS]] : https://build.meego.com/ - used by core developers to build the main MeeGo distribution; accounts provided to anyone who earns commit rights to a MeeGo package. More information on how to get an account can be found [[Build_Infrastructure/Packagers_Developers#How_to_get_started|here]]
* The [[OBS/Community OBS|Community OBS]] : https://build.pub.meego.com/ - used by MeeGo community members to build opensource applications and libraries

Additionally vendors may have private OBS installations

OBS installations may be linked to each other so that software build on a vendor OBS or the community OBS may refer to and track software packages being developed on the core OBS.

Whilst the OBS does the bulk of the compiling and building there is additional QA, automation and test infrastructure used by the MeeGo Project : The [[Build Infrastructure]] article has more details.

'''OBS Documentation'''

* Documentation root: [[Build Infrastructure/Packagers Developers]]
* OSC tutorial: [[Build Infrastructure/Packagers Developers/CLI Part 1]]

'''Get a Community OBS account'''

https://build.pub.meego.com/user/register_user

'''Setup a local test instance'''

There is a wiki article on how to [[OBS setup|setup a Build Service of your own]] - note that you don't need to do this to build locally; it's only usually needed by vendors.

Build Infrastructure/Packagers Developers

2011-05-30T22:54:30Z

Gabrbedd: Add troubleshooting section with the "Package already exists: %package debuginfo" error.

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 of projects, commit]]
* Part 3 - [http://en.opensuse.org/openSUSE:OSC branch, edit, localbuild, commit, submitreq]
* part 4 - [[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 or #meego-dev 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]]

Hardware References and Resources

2011-05-29T15:01:03Z

Gabrbedd:

This page is a stub for future community-led hardware development. Stay tuned!

-- Resources/References --

* http://www.raspberrypi.org/
* http://www.openpandora.org/
* http://opencircuits.org/
* http://cellphonediagram.com/search/homebuilt-rx-tx-rf/
* http://en.wikipedia.org/wiki/JooJoo (lessons to be learned!)
* http://en.wikipedia.org/wiki/OLPC
* http://www.openmoko.com (They've actually produced a phone)

MeeGo Conference Spring 2011/Flight Information

2011-05-17T15:28:40Z

Gabrbedd: /* Sunday 22 */

== Flight Information ==

Keep the entries sorted by time and date.

===Meeting point===
TBC

===Arrivals===

====Thursday 19====

{| border="1"
! Time
! Name
! Place of arrival
! Means of transport
! Comments
|-
| 11:50
| Matti Saastamoinen ([http://meego.com/users/smoinen smoinen])
| Airport (SFO)
| DL9311 from AMS
| origin: HEL
|-
|-
| 19:05
| Erik Stein ([http://meego.com/users/erikstein erikstein])
| Airport (SFO)
| AA1835 from Chicago
| origin: Berlin (SXF) via Dublin (DUB)
|-
|}

====Friday 20====

{| border="1"
! Time
! Name
! Place of arrival
! Means of transport
! Comments
|-
| 11:50
| Jarkko Moilanen ([http://meego.com/users/kyber kyb3R])
| Airport (SFO)
| KL605 from Amsterdam
|
|-
| 11:50
| Andre Klapper ([http://meego.com/users/andre andre])
| Airport (SFO)
| KL605 from Amsterdam
|
|-
| 11:50
| [http://meego.com/users/timeless timeless]
| Airport (SFO)
| KL605 from Amsterdam
| origin: KL1164 (HEL)
|-
| 11:50
| Michael Hasselmann ([http://meego.com/users/mikhas mikhas])
| Airport (SFO)
| KL605 from Amsterdam
|-
| 11:55
| Cornelius Hald ([http://meego.com/users/conny conny])
| Airport (SFO)
| LH454 from Frankfurt (FRA)
| origin: Dresden (DRS)
|-
| 11:55
| Cosimo Kroll ([http://meetmeego.org/about/ zehjotkah])
| Airport (SFO)
| LH454 from Frankfurt (FRA)
| origin: Berlin (TXL)
|-
| 11:55
| Eric Le Roux ([http://meego.com/users/ericlr ericlr])
| Airport (SFO)
| LH454 from Frankfurt (FRA)
| origin: Helsinki (HEL)
|-
| 11:55
| Dariusz Filipski ([http://meego.com/users/Darek Darek])
| Airport (SFO)
| LH454 from Frankfurt (FRA)
| origin: Helsinki (HEL)
|-
| 12:50
| [http://meego.com/users/dneary Dave Neary]
| Airport (SFO)
| AF84 from Paris
|
|-
| 14:20
| Timo Rongas ([http://meego.com/users/ronksu ronksu])
| Airport (SFO)
| BA285 from London (LHR)
|
|-
| 15:50
| [http://meego.com/users/timsamoff Tim Samoff]
| Airport (OAK) then BART
| WN2012 from Burbank (BUR)
|
|-
| 19:10
| [http://meego.com/users/vivainio Ville M. Vainio]
| Airport (SFO)
| LH458 from MUC
|
|-
| 21:35
| Attila Csipa ([http://meego.com/users/achipa achipa])
| Airport (SFO)
| AA177 from JFK
|
|-
|}

====Saturday 21====

{| border="1"
! Time
! Name
! Place of arrival
! Means of transport
! Comments
|-
| 00:35
| Dan Leinir Turthra Jensen ([http://meego.com/users/leinir leinir])
| Airport (SFO)
| UA225 from Washington (IAD)
| origin: London (LHR)
|-
| 11:55
| Arek Stopczynski ([http://meego.com/users/hopbeat hopbeat])
| Airport (SFO)
| LH454 from Frankfurt
|
|-
| 11:55
| Jukka Eklund ([http://meego.com/users/jukka jukka])
| Airport (SFO)
| LH454 from Frankfurt
|
|-
| 14:20
| Timo Härkönen ([http://meego.com/users/timoph timoph])
| Airport (SFO)
| BA0285 from LHR
|
|-
| 14:20
| Iekku Huttunen([http://meego.com/users/iekku iekku])
| Airport (SFO)
| BA0285 from LHR
|
|-
| 15:50
| Andrew Flegg ([http://meego.com/users/jaffa Jaffa])
| Airport (SFO)
| VS019 from LHR
|
|-
| 15:50
| Tom Swindell ([http://meego.com/users/tswindell Alterego])
| Airport (SFO)
| VS019 from LHR
|
|-
| 16:45
| Jarno Teivas ([http://meego.com/users/jarnoteivas jarnoteivas])
| Airport (SFO)
| BA0287 from LHR
|
|-
| 16:45
| Anssi Takku ([http://meego.com/users/zotte zotte])
| Airport (SFO)
| BA0287 from LHR
|
|-
| 17:18
| [http://meego.com/users/myrtti Miia Ranta]
| Airport (SFO)
| UA931 from LHR
|
|-
| 17:18
| [http://meego.com/users/dsample Duncan Sample]
| Airport (SFO)
| UA931 from LHR
|
|-
| 19:10
| Thiago Macieira ([http://meego.com/users/thiago thiago])
| Airport (SFO)
| LH458 from Munich (MUC)
|
|-
| 19:20
| Ryan Abel ([http://meego.com/users/generalantilles GeneralAntilles])
| Airport (SFO)
| AA515 from Dallas Ft. Worth DFW
|
|-
| 19:53
| Andrea Grandi ([http://meego.com/users/andreagrandi AndreaGrandi])
| Airport (SFO)
| LH9126 from Frankfurt
| origin: Florence (FLR)
|-
| 19:53
| Thomas Perl ([http://meego.com/users/thp thp])
| Airport (SFO)
| LH9126 from Frankfurt
| origin: Vienna (VIE)
|-
| 21:18
| Brendan Le Foll ([http://meego.com/users/arfoll arfoll])
| Airport (SFO)
| 133 from JFK
| origin: Barcelona (BCN)
|-
| 23:05
| Jerry Jalava ([http://meego.com/users/Wick3d Wick3d])
| Airport (SFO)
| AA17 from JFK
| origin: Finland (HEL)
|}

====Sunday 22====

{| border="1"
! Time
! Name
! Place of arrival
! Means of transport
! Comments
|-
| 10:30
| Gabriel Beddingfield ([http://meego.com/users/gabrbedd gabrbedd])
| Airport (SFO)
| AA1581 from DFW
|
|-
| 11:40
| Reggie Suplido ([http://meego.com/users/reggie reggie])
| Airport (SFO)
| UA759 from ORD
|
|-
| 12:13
| Alan Bruce ([http://meego.com/users/qole qole])
| Airport (SFO)
| WS1776 from Vancouver
|
|-
| 12:35
| Andrew Olmsted ([http://meego.com/users/fiferboy fiferboy])
| Airport (SFO)
| AC757 from YYZ
|
|-
| 20:28
| Stephen Gadsby ([http://meego.com/users/sjgadsby sjgadsby])
| Airport (SFO)
| CO6516 from DEN
|
|-
| sometime in the afternoon (early)
| Aniello Del Sorbo ([http://meego.com/users/anidel anidel])
| Straight to the Hyatt
| By car (travelling from Las Vegas)
|
|-
|}

===Departures===

====Wednesday 25====

{| border="1"
! Time
! Name
! Place of departure
! Means of transport
! Comments
|-
| 14:00
| Matti Saastamoinen ([http://meego.com/users/smoinen smoinen])
| Airport (SFO)
| DL9381 to AMS
|
|-
| 14:40
| Alan Bruce ([http://meego.com/users/qole qole])
| Airport (SFO)
| WS1563 to Calgary
|
|-
| 19:01
| Andrea Grandi ([http://meego.com/users/andreagrandi AndreaGrandi])
| Airport (SFO)
| LH9127 to Frankfurt
|
|-
| 21:05
| Thomas Perl ([http://meego.com/users/thp thp])
| Airport (SFO)
| LH0459 to Munich (MUC)
|
|-
| 22:10
| Stephen Gadsby ([http://meego.com/users/sjgadsby sjgadsby])
| Airport (SFO)
| CO1804 to ORD
|
|-
|}

====Thursday 26====

{| border="1"
! Time
! Name
! Place of departure
! Means of transport
! Comments
|-
| 07:10
| Attila Csipa ([http://meego.com/users/achipa achipa])
| Airport (SFO)
| AA24 to JFK
|
|-
| 11:30
| Dan Leinir Turthra Jensen ([http://meego.com/user/leinir leinir])
| Airport (SFO)
| AC563 to LHR (via IAD)
|
|-
| 11:30
| [http://meego.com/users/timsamoff Tim Samoff]
| BART Station
| BART to OAK
|
|-
| 13:15
| Andrew Olmsted ([http://meego.com/users/fiferboy fiferboy])
| Airport (SFO)
| AC756 to YYZ
|
|-
| 13:30
| [http://meego.com/users/timsamoff Tim Samoff]
| Airport (OAK)
| WN301 to BUR
|
|-
| 13:48
| [http://meego.com/users/vivainio Ville M. Vainio]
| Airport (SFO)
| UA900 To Frankfurt (FRA)
|
|-
| 14:00
| Jarkko Moilanen ([http://meego.com/users/kyber kyb3R])
| Airport (SFO)
| KL606 to AMS
|
|-
| 14:00
| [http://meego.com/users/dneary Dave Neary]
| Airport (SFO)
| KL606 to AMS
|
|-
| 14:00
| Andre Klapper ([http://meego.com/users/andre andre])
| Airport (SFO)
| KL606 to AMS
|
|-
| 14:20
| Cosimo Kroll ([http://meetmeego.org/about/ zehjotkah])
| Airport (SFO)
| LH455 to Frankfurt (FRA)
|
|-
| 14:20
| Jukka Eklund ([http://meego.com/users/jukka jukka])
| Airport (SFO)
| LH455 to Frankfurt (FRA)
|
|-
| 15:10
| Gabriel Beddingfield ([http://meego.com/users/gabrbedd gabrbedd])
| Airport (SFO)
| AA566 to DFW
|
|-
| 18:55
| Timo Härkönen ([http://meego.com/users/timoph timoph])
| Airport (SFO)
| BA0286 to LHR
|
|-
| 18:55
| Iekku Huttunen ([http://meego.com/users/iekku iekku])
| Airport (SFO)
| BA0286 to LHR
|
|-
| 18:55
| Jarno Teivas ([http://meego.com/users/jarnoteivas jarnoteivas])
| Airport (SFO)
| BA0286 to LHR
|
|-
| 18:55
| Anssi Takku ([http://meego.com/users/zotte zotte])
| Airport (SFO)
| BA0286 to LHR
|
|-
| 19:01
| Arek Stopczynski ([http://meego.com/users/hopbeat hopbeat])
| Airport (SFO)
| LH9127 to Frankfurt
|
|-
| 19:05
| Andrew Flegg ([http://meego.com/users/jaffa Jaffa])
| Airport (SFO)
| VS020 to LHR
|
|-
| 19:05
| Tom Swindell ([http://meego.com/users/tswindell Alterego])
| Airport (SFO)
| VS020 to LHR
|
|}

====Friday 27====

{| border="1"
! Time
! Name
! Place of departure
! Means of transport
! Comments
|-
| 07:10
| Jerry Jalava ([http://meego.com/users/Wick3d Wick3d])
| Airport (SFO)
| AA24 to JFK / AA7160 to HEL
|
|-
| 13:20
| [http://meego.com/users/timeless timeless]
| Airport (SJC)
| WN1113 to BUR
|
|-
| 13:48
| Cornelius Hald ([http://meego.com/users/conny conny])
| Airport (SFO)
| LH9053 to Frankfurt
|
|-
| 14:15
| Eric Le Roux ([http://meego.com/users/ericlr ericlr])
| Airport (SFO)
| LH455 to Frankfurt / LH850 to Helsinki
|
|}

====Sunday 29====

{| border="1"
! Time
! Name
! Place of departure
! Means of transport
! Comments
|-
| 09:50
| Ryan Abel ([http://meego.com/users/generalantilles GeneralAntilles])
| Airport (SJC)
| AA1543 to Dallas Ft. Worth
|
|-
| 11:00
| Erik Stein ([http://meego.com/users/erikstein erikstein])
| Airport (SFO)
| AA1544 to Chicago
|
|}

MeeGo Conference Spring 2011/Accommodation

2011-05-13T00:22:48Z

Gabrbedd:

The MeeGo Conference has a special rate with the [http://sf2011.meego.com/logistics/hotel San Francisco Hyatt Regency Embarcadero Center]. If you have been approved for sponsored travel, please ensure that you have booked a room at the Hyatt through the [https://www.eiseverywhere.com/ereg/index.php?eventid=19946 conference registration tool] already. The hotel will modify your reservation based upon the input provided below.

Sponsored participants will receive up to 4 nights in the conference hotel, in a dual occupancy room. MeeGo will pay for the room rate and taxes for 4 nights, and you will be responsible for any other charges to the room. Please note the total duration of your stay below (e.g., arriving early for Conference Warm Up or staying a night after the conference).

If sponsored attendees do not have a roommate preference, we'll assign one for you. All roommates must also be conference attendees. If you request a roommate that is not sponsored, they will be responsible for the remainder of the room fee.

If you plan to spend more time in San Francisco and would like to share costs with a roommate before or after the conference, please note it in the last table. This is for convenience and matching roommates only; you will need to manage your own hotel reservations for these nights.

{| border="1"
|-
!colspan="3"|Roommate 1
!colspan="3"| Roommate 2
!rowspan="2" style="width:200px"| Considerations
|-
!style="width:200px"|Name
!style="width:100px"|Arrive
!style="width:100px"|Depart
!style="width:200px"|Name
!style="width:100px"|Arrive
!style="width:100px"|Depart
|-
|Alan Bruce||May 22||May 25||Stephen Gadsby||May 22||May 25||
|-
|Andrea Grandi||May 21||May 25||Cornelius Hald||May 21||May 25||
|-
|Andrew Flegg||21 May||26 May||Tim Samoff||20 May, 15:50||23 May (switching hotels, but will be in SF through the 26th)||
|-
|Andrew Olmsted||22 May||26 May || Andrew Zhilin? || || ||
|-
|Andrew Zhilin|| || || || || ||
|-
|Anselmo Lacerda S. de Melo||22 May||26 May||Artur Souza||22 May||26 May||
|-
|Brendan Le Foll|| || || || || ||
|-
|Dan Leinir Turthra Jensen|| || || || || ||
|-
|Dave Neary||20 May||26 May||Julien Fourgeaud||20 May||26 May||
|-
|Dimitris Glezos|| || || || || ||
|-
|Ed Page|| May 21st @ 10:00am || May 26th at 4:00pm || || || ||
|-
|Felipe Crochik||22nd ||25th || Robert Bauer || May 21 6:00pm || May 25 7:00am ||
|-
|Ferenc Szekely|| May 20th || May 28th || || || ||
|-
|Frank Karlitschek||22nd ||26th || || || ||
|-
|Gabriel Beddingfield|| May 22nd || May 26th || || || ||
|-
|Gustavo Padovan||May 22nd || May 26th || || || ||
|-
|Hashiq Nazir|| May 20th || May 25th || Zak borg || || ||
|-
|Jakob Eg Larsen|| 21 May || 25 May || Arkadiusz Stopczynski || 21 May || 25 May ||
|-
|Jarkko Moilanen|| || || || || ||
|-
|Josh Soref|| May 22nd || May 26th || || || ||
|-
|Maitrey Mishra|| || || || || ||
|-
|Michael Hasselmann|| May 20th || June 4th || Thomas Perl || May 21st || May 25th ||
|-
|Michał Sawicz|| May 20th || May 28th || || || || MS moving out of Hyatt on May 24th
|-
|Miia Ranta|| May 21st || May 25th || Duncan Sample ||May 21st || May 25th||
|-
|Mitul Bhat|| || || || || ||
|-
|Niels Mayer|| || || || || ||
|-
|Randall Arnold||21 May 10:30 AM||26 May 5:30 PM||Jens Wiik|| 2011-05-21 21:30|| 2011-05-26 07:10 ||
|-
|Sivan Greenberg|| || || || || ||
|-

|Tom Swindell||21 May||25 May|| || || ||
|-
|Uladzislau Vasilyeu||May 22 ||May 26 ||Tatsiana Makava ||May 22 ||May 26 ||
|-
|Zak Borg||20 May ||25 May || || || ||

|}

== Non-Conference Lodging ==

If you plan to stay in San Francisco after May 26 and are looking for a roommate to share costs, note it here. You will be responsible for making your own lodging arrangements, and these nights are not eligible for MeeGo sponsorship.

{| border="1"
|-
!colspan="3"|Roommate 1
!colspan="3"| Roommate 2
!rowspan="2" style="width:200px"| Considerations
|-
!style="width:200px"|Name
!style="width:100px"|Arrive
!style="width:100px"|Depart
!style="width:200px"|Name
!style="width:100px"|Arrive
!style="width:100px"|Depart
|-
|Your name
|May 21
|May 25
|Your roommate's name
|May 21
|May 25
|Staying in different hotel, etc
|-
| Ferenc Szekely || May 24th || May 28th || || || || Ferenc: Planning to stay in Hyatt
|-
|}

Quality/bkm/corewatcher

2011-04-30T02:26:26Z

Gabrbedd: Expand info on corewatcher

=Corewatcher=

Corewatcher is a program that collects user space program crash information and then submits signature information and backtrace data to a central website for for statistical analysis and presentation to
distribution developers. If your system is configured to create core dumps when a program crashes, corewatcher will analyze the core dumps and report the information back to a central site.

For MeeGo development, core dumps are enabled and corewatcher runs by default (since 1.1.90). When a crash happens, it will ask you if you wish to submit the information to MeeGo (http://crashdb.meego.com). You can also visit that site to see what the hot items currently are.

==Configuring==

The configuration file is /etc/corewatcher.conf. That file is very well documented, so refer to it for further information. It is highly recommended that you edit this file to change 'allow-submit' from 'ask' to 'yes'. (It's near the top)

<pre>allow-submit = yes</pre>

The reason is that the 'ask' isn't always working, in which case the core dumps and corewatcher will fill up your hard drive with the data in /tmp.

==Getting the Backtraces==
Here are the steps of how to get the backtrace log of a crashed program on meego handset
* Find the "core" logs files under /tmp.
** When a program crashed, there will be a "core" file (file name like "core.xxx") generated under /tmp automatically.
** The current MeeGo supports it by default, no additional package needed.
* Find which "core" log is for the crashed program.
** In /tmp, there could be more than one "core" file, choose the latest one.
** For example, if the crashed program is "meego-handset-people", and the latest "core" log is "core.1000", we can user command "file core.1000" to check whether the "core" log is generated for "meego-handset-people".
** If it isn't, we could try the next latest "core" log with file command until we find the correct one
* Use gdb to get the backtrace information of this crash.
** Gdb hasn't been installed on the latest MeeGo image, we have to install it before we can get the backtrace information
** Before start gdb, run comman "script" command to record the following screen output
** Let’s still use "meego-handset-people" and "core.1000" for an example. Run command "gdb /usr/bin/meego-handset-people core.1000".
** Firstly, gdb starts to reproduce the crashing process recorded in "core.1000". When it stops, we can input "bt" command in gdb console, and it starts to dump the backtrace of this crash.
** After all backtrace is shown, input "quit" to leave gdb.
** Input "exit" command to stop "script", and we get the screen output in "typescript" under the current folder
** Open "typescript", the content after "bt" command is the backtrace we need for this crash

==Troubleshooting==

'''''Corewatcher is filling up my hard drive''''' — For some reason your dumps are not being submitted to the MeeGo server, and therefore they are being retained in your /tmp folder. The easiest solution (after `rm -rf /tmp/core*`) is to change 'allow-submit' from 'ask' to 'yes' (see [[#Configuring]]).

MeeGo Conference Spring 2011/Flight Information

2011-04-26T00:29:00Z

Gabrbedd: /* Sunday 22 */

== Flight Information ==

Keep the entries sorted by time and date.

===Meeting point===
TBC

===Arrivals===

====Friday 20====

{| border="1"
! Time
! Name
! Place of arrival
! Means of transport
! Comments
|-
| 11:55
| Cornelius Hald ([http://meego.com/users/conny conny])
| Airport (SFO)
| LH454 from Frankfurt (origin: Dresden (DRS))
|
|-
|-
| 21:35
| Attila Csipa ([http://meego.com/users/achipa achipa])
| Airport (SFO)
| AA177 from JFK
|
|-
|}

====Saturday 21====

{| border="1"
! Time
! Name
! Place of arrival
! Means of transport
! Comments
|-
| 15:50
| Andrew Flegg ([http://meego.com/users/jaffa Jaffa])
| Airport (SFO)
| VS019 from LHR
|
|-
| 19:53
| Andrea Grandi ([http://meego.com/users/andreagrandi AndreaGrandi])
| Airport (SFO)
| LH9126 from Frankfurt (origin: Florence (FLR))
|
|-
| 19:53
| Thomas Perl ([http://meego.com/users/thp thp])
| Airport (SFO)
| LH9126 from Frankfurt (origin: Vienna (VIE))
|
|}

====Sunday 22====

{| border="1"
! Time
! Name
! Place of arrival
! Means of transport
! Comments
|-
| 10:30
| Gabriel Beddingfield ([http://meego.com/users/gabrbedd gabrbedd])
| SFO
| AA from DFW
|
|-
| 20:28
| Stephen Gadsby ([http://meego.com/users/sjgadsby sjgadsby])
| Airport (SFO)
| CO6516 from DEN
|
|-
|}

===Departures===

====Wednsday 25====

{| border="1"
! Time
! Name
! Place of departure
! Means of transport
! Comments
|-
| 19:01
| Andrea Grandi ([http://meego.com/users/andreagrandi AndreaGrandi])
| Airport (SFO)
| LH9127 to Frankfurt
|
|-
| 21:05
| Thomas Perl ([http://meego.com/users/thp thp])
| Airport (SFO)
| LH0459 to Munich (MUC)
|
|-
| 22:10
| Stephen Gadsby ([http://meego.com/users/sjgadsby sjgadsby])
| Airport (SFO)
| CO1804 to ORD
|
|-
|}

====Thursday 26====

{| border="1"
! Time
! Name
! Place of departure
! Means of transport
! Comments
|-
| 07:10
| Attila Csipa ([http://meego.com/users/achipa achipa])
| Airport (SFO)
| AA24 to JFK
|
|-
| 15:10
| Gabriel Beddingfield ([http://meego.com/users/gabrbedd gabrbedd])
| Airport (SFO)
| AA to DFW
|
|-
| 19:05
| Andrew Flegg ([http://meego.com/users/jaffa Jaffa])
| Airport (SFO)
| VS020 to LHR
|
|}

====Friday 27====

{| border="1"
! Time
! Name
! Place of departure
! Means of transport
! Comments
|-
| 13:48
| Cornelius Hald ([http://meego.com/users/conny conny])
| Airport (SFO)
| LH9053 to Frankfurt
|
|}

MeeGo Conference Spring 2011/Flight Information

2011-04-26T00:28:38Z

Gabrbedd: /* Thursday 26 */

== Flight Information ==

Keep the entries sorted by time and date.

===Meeting point===
TBC

===Arrivals===

====Friday 20====

{| border="1"
! Time
! Name
! Place of arrival
! Means of transport
! Comments
|-
| 11:55
| Cornelius Hald ([http://meego.com/users/conny conny])
| Airport (SFO)
| LH454 from Frankfurt (origin: Dresden (DRS))
|
|-
|-
| 21:35
| Attila Csipa ([http://meego.com/users/achipa achipa])
| Airport (SFO)
| AA177 from JFK
|
|-
|}

====Saturday 21====

{| border="1"
! Time
! Name
! Place of arrival
! Means of transport
! Comments
|-
| 15:50
| Andrew Flegg ([http://meego.com/users/jaffa Jaffa])
| Airport (SFO)
| VS019 from LHR
|
|-
| 19:53
| Andrea Grandi ([http://meego.com/users/andreagrandi AndreaGrandi])
| Airport (SFO)
| LH9126 from Frankfurt (origin: Florence (FLR))
|
|-
| 19:53
| Thomas Perl ([http://meego.com/users/thp thp])
| Airport (SFO)
| LH9126 from Frankfurt (origin: Vienna (VIE))
|
|}

====Sunday 22====

{| border="1"
! Time
! Name
! Place of arrival
! Means of transport
! Comments
|-
| 10:30
| Gabriel Beddingfield ([http://meego.com/users/gabrbedd gabrbedd])
| SFO
| DC-10
|
|-
| 20:28
| Stephen Gadsby ([http://meego.com/users/sjgadsby sjgadsby])
| Airport (SFO)
| CO6516 from DEN
|
|-
|}

===Departures===

====Wednsday 25====

{| border="1"
! Time
! Name
! Place of departure
! Means of transport
! Comments
|-
| 19:01
| Andrea Grandi ([http://meego.com/users/andreagrandi AndreaGrandi])
| Airport (SFO)
| LH9127 to Frankfurt
|
|-
| 21:05
| Thomas Perl ([http://meego.com/users/thp thp])
| Airport (SFO)
| LH0459 to Munich (MUC)
|
|-
| 22:10
| Stephen Gadsby ([http://meego.com/users/sjgadsby sjgadsby])
| Airport (SFO)
| CO1804 to ORD
|
|-
|}

====Thursday 26====

{| border="1"
! Time
! Name
! Place of departure
! Means of transport
! Comments
|-
| 07:10
| Attila Csipa ([http://meego.com/users/achipa achipa])
| Airport (SFO)
| AA24 to JFK
|
|-
| 15:10
| Gabriel Beddingfield ([http://meego.com/users/gabrbedd gabrbedd])
| Airport (SFO)
| AA to DFW
|
|-
| 19:05
| Andrew Flegg ([http://meego.com/users/jaffa Jaffa])
| Airport (SFO)
| VS020 to LHR
|
|}

====Friday 27====

{| border="1"
! Time
! Name
! Place of departure
! Means of transport
! Comments
|-
| 13:48
| Cornelius Hald ([http://meego.com/users/conny conny])
| Airport (SFO)
| LH9053 to Frankfurt
|
|}

MeeGo Conference Spring 2011/Flight Information

2011-04-26T00:26:45Z

Gabrbedd: /* Sunday 22 */

== Flight Information ==

Keep the entries sorted by time and date.

===Meeting point===
TBC

===Arrivals===

====Friday 20====

{| border="1"
! Time
! Name
! Place of arrival
! Means of transport
! Comments
|-
| 11:55
| Cornelius Hald ([http://meego.com/users/conny conny])
| Airport (SFO)
| LH454 from Frankfurt (origin: Dresden (DRS))
|
|-
|-
| 21:35
| Attila Csipa ([http://meego.com/users/achipa achipa])
| Airport (SFO)
| AA177 from JFK
|
|-
|}

====Saturday 21====

{| border="1"
! Time
! Name
! Place of arrival
! Means of transport
! Comments
|-
| 15:50
| Andrew Flegg ([http://meego.com/users/jaffa Jaffa])
| Airport (SFO)
| VS019 from LHR
|
|-
| 19:53
| Andrea Grandi ([http://meego.com/users/andreagrandi AndreaGrandi])
| Airport (SFO)
| LH9126 from Frankfurt (origin: Florence (FLR))
|
|-
| 19:53
| Thomas Perl ([http://meego.com/users/thp thp])
| Airport (SFO)
| LH9126 from Frankfurt (origin: Vienna (VIE))
|
|}

====Sunday 22====

{| border="1"
! Time
! Name
! Place of arrival
! Means of transport
! Comments
|-
| 10:30
| Gabriel Beddingfield ([http://meego.com/users/gabrbedd gabrbedd])
| SFO
| DC-10
|
|-
| 20:28
| Stephen Gadsby ([http://meego.com/users/sjgadsby sjgadsby])
| Airport (SFO)
| CO6516 from DEN
|
|-
|}

===Departures===

====Wednsday 25====

{| border="1"
! Time
! Name
! Place of departure
! Means of transport
! Comments
|-
| 19:01
| Andrea Grandi ([http://meego.com/users/andreagrandi AndreaGrandi])
| Airport (SFO)
| LH9127 to Frankfurt
|
|-
| 21:05
| Thomas Perl ([http://meego.com/users/thp thp])
| Airport (SFO)
| LH0459 to Munich (MUC)
|
|-
| 22:10
| Stephen Gadsby ([http://meego.com/users/sjgadsby sjgadsby])
| Airport (SFO)
| CO1804 to ORD
|
|-
|}

====Thursday 26====

{| border="1"
! Time
! Name
! Place of departure
! Means of transport
! Comments
|-
| 07:10
| Attila Csipa ([http://meego.com/users/achipa achipa])
| Airport (SFO)
| AA24 to JFK
|
|-
| 19:05
| Andrew Flegg ([http://meego.com/users/jaffa Jaffa])
| Airport (SFO)
| VS020 to LHR
|
|}

====Friday 27====

{| border="1"
! Time
! Name
! Place of departure
! Means of transport
! Comments
|-
| 13:48
| Cornelius Hald ([http://meego.com/users/conny conny])
| Airport (SFO)
| LH9053 to Frankfurt
|
|}

Spectacle

2011-03-25T17:35:51Z

Gabrbedd: Add details about changelogs.

== Introduction ==

Spectacle is the toolset for packaging maintenance of MeeGo, including the tool
to generate spec files from metadata file in YAML format, and tools to convert
spec files or spec-builder's ini files to YAML format.

For spectacle managed packages, all generic packaging information will be stored
in the YAML file, and it also allows maintaining customizations in the spec file
directly with special enclosure tags.

Three separated tools will be installed:

* specify: the tool to generate or to update spec file, based on YAML
* ini2spectacle: the tool to convert spec-builder .ini to YAML and new spec file
* spec2spectacle: the tool to convert original spec to YAML and new spec file

== Installation ==
=== Instruction ===
Several methods available for spectacle installation:

* Install rpm/deb packages for several supported Linux distributions.
From [http://repo.meego.com/tools/repos/ MeeGo Tools Repo], repo urls and install packages can be found for:
* MeeGo
* Fedora 10,11,12
* openSUSE(s)
* xUbuntu 8.10/9.04/9.10/10.04
* Debian 5.0

* Build from the latest source and install it by ``make install``
The latest code in git tree can be accessed at:
[git://gitorious.org/meego-developer-tools/spectacle.git]

'''Note on Ubuntu installation'''
From [http://bugs.meego.com/show_bug.cgi?id=6734 this] Edit or create ''/etc/apt/sources.list.d/meego.list'' with sudo
Add
deb http://repo.meego.com/MeeGo/tools/repos/ubuntu/9.10/ /

run the following commands
sudo apt-get update

=== Requirements ===
* python 2.x, above 2.5
* PyYAML, the python module for YAML parsing
* cheetah, one popular templating system for python 
In many linux distributions, the needed package might be "python-cheetah".

== Usage ==
* specify
Usage: specify [options] [yaml-path]
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-o OUTFILE_PATH, --output=OUTFILE_PATH
Path of output spec file
-s, --skip-scm Skip to check upstream SCM when specified in YAML
-N, --not-download Do not try to download newer source files
-n, --non-interactive
Non interactive running, to use default answers
--new=NEWYAML Create a new yaml from template
--newsub=NEWSUB Append a new sub-package to current yaml

For example, `specify widget.yaml` will create (or update) the file widget.spec. The update will clobber/delete everything that is not enclosed in the customization sections (<<< and >>>). Note that the %changelog section will always be clobbered (see Tips below about changelogs).

* ini2spectacle
Usage: ini2spectacle [options] [ini-path]
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-o OUTFILE_PATH, --output=OUTFILE_PATH
Path of output yaml file
-f, --include-files To store files list in YAML file

* spec2spectacle
Usage: spec2spectacle [options] [spec-path]
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-o OUTFILE_PATH, --output=OUTFILE_PATH
Path of output yaml file
-r, --replace-macros To replace self-defined macros in spec file
--no-builder-parsing Do NOT try to parse build/install scripts
-f, --include-files To store files list in YAML file

== Syntax of spectacle YAML ==
The syntax of YAML can be refered here: <http://www.yaml.org/spec/>

Two example spectacle YAML files are placed to examples/ directory in source
code:

* xfce4-session.yaml, a real world sample with most of the elements
* general.yaml, a fake spectacle contains all the available elements with comments

All available directives for spectacle are listed as the following:

* Name: **string**

* Summary: **string**

* Version: **string**, version string

* Release: **string**

* Epoch: **string**, *optional*

* Group: **string**

* License: **string**

* URL: **string**, *optional*

* BuildArch: **string**, *optional*

* ExclusiveArch: **string**, *optional*

* Prefix: **string**, *optional*

* LocaleName: **string**, *optional*

* LocaleOptions: **string**, *optional*

* Description: **text**, *optional*

* Sources: **list** of **string**

* SourcePrefix: **string**, *optional*, specify the prefix path in source package

* ExtraSources: **list** of **string**, *optional*

* SetupOptions: **string**, *optional*, the options string for %setup

* Patches: **list** of **string**, all patches need to be in 'p1' level

* Requires: **list** of **string**

* RequiresPre: **list** of **string**

* RequiresPreUn: **list** of **string**

* RequiresPost: **list** of **string**

* RequiresPostUn: **list** of **string**

* PkgBR: **list** of **string**, packages required in building, or BuildRequires

* PkgConfigBR: **list** of **string**, pkg-config requires in building

* Provides: **list** of **string**

* Conflicts: **list** of **string**

* Obsoletes: **list** of **string**

* BuildConflicts: **list** of **string**

* Configure: **string**, *optional*, valid values: **autogen**, **configure**, **reconfigure**, **none** 
** If not specified, the default value "configure" will be used

* ConfigOptions: **list**, *optional*, extra options for ``Configure``

* Builder: **string**, *optional*, valid values: **make**, **single-make**, **python**, **perl**, **qmake**, **none** 
** If not specified, the deault value "make" will be used. If do not want a automatic builder, please use "none".

* QMakeOptions: **list**, *optional*, extra options for **qmake** ``Builder``

* Files: **list** of **string**, *optional*, content of ``%files`` for small packages

* FilesInput: **string**, *optional*, extra input source for %files

* NoFiles: **boolean**, *optional*, if to be set as True, means no %files section for this package and it cause no rpm generated

* RunFdupes: **list** of **string**, paths under %{buildroot} to run ``%fdupes`` macro in %install

* RpmLintIgnore: **list**, *optional*, list of skip items for ``rpmlint``

* Check: **boolean**, whether need ``%check`` section in spec

* SupportOtherDistros: **boolean**, whether need to check for other distros (besides MeeGo)

* UseAsNeeded: **boolean**, whether export LD\_AS\_NEEDED=1 environ variable before building

* NoAutoReq: **boolean**, whether add 'AutoReq: 0' to spec

* NoAutoProv: **boolean**, whether add 'AutoProv: 0' to spec

* NoSetup: **boolean**, whether to skip using ``%setup`` in ``%prep``

* NoAutoLocale: **boolean**, whether to use ``%find_lang`` to search locale data when found 'intltool' in PkgBR

* NoDesktop: **boolean**, whether to install the desktop files in package

* UpdateDesktopDB: **boolean**, whether to run 'update-desktop-database' to flush cache when package (un)installation

* NoIconCache: **boolean**, whether to run 'gtk-update-icon-cache' if icon files found in package

* AutoDepend: **boolean**, for subpackages only, whether to add Require to main package automatically

* AsWholeName: **boolean**, for subpackages only, whether to use **Name** as the whole package name

* AutoSubPackages: **list** of **string**, mainly for '-devel'

* SubPackages: **list** of **dict**, the **dict** item is the lower level directives for sub packages:

* Name
* Summary
* Description, *optional*
* Group, *optional*
* License, *optional*
* Requires, *optional*
* etc.

'''CAUTION''': The following cases of value string have special meaning in YAML syntax:
* string with leading **``%``** charactor
* string with leading **``*``** charactor
* string contains **``:``** charactor and one or more spaces/tabs after **``:``**
* string end with **``:``** charactor

Then these string values need to be quoted by ``'``(single-quote) or ``"``
(double-quote), and the choice of quote char should not conflict with the value
string self.

== Mandatory and valid keywords for all packages ==
=== Mandatory keywords ===
The following keywords are mandatory for main package:

* Name
* Summary
* Description
* Version
* Group
* License

The following keywords are mandatory for sub-package:

* Name
* Summary
* Description
* Group

=== Valid keywords for sub-packages ===
For sub-packages, only a subset of keywords can be specified:

* Name
* Summary
* Description
* Group
* License
* Version
* Release
* Epoch
* URL
* BuildArch
* Files
* Prefix
* Requires
* RequiresPre
* RequiresPreUn
* RequiresPost
* RequiresPostUn
* Provides
* Conflicts
* Obsoletes
* NoAutoReq
* NoAutoProv
* NoAutoReqProv
* NoIconCache
* FilesInput

=== Keywords only for sub-packages ===
The following keywords are only valid for sub-packages:

* AsWholeName
* AutoDepend

== Namespace support for multi-architecture in several keywords ==
For the following spectacle YAML keywords:

* Requires
* PkgBR
* PkgConfigBR
* Patches
* ConfigOptions
* QMakeOptions

If one of the items need to be architecture specified, we can add arch prefix to
it. The supported prefix and the corresponding architectures as the followings:

* ``ix86:`` - x86 platform
* ``arm:`` - arm platform
* ``armv5:`` - armv5 platform, will expand to "armv5el armv5tel armv5tejl"
* ``armv7:`` - armv7 platform, will expand to "armv7el armv7tel armv7l armv7hl armv7nhl"

Here's some samples:

Requires:
- arm:pkg-need-in-arm-image
- ix86:pkg-need-in-x86-image
- normal-pkg
ConfigOptions:
- arm:--arm-specific-opt
- ix86:--ix86-specific-opt
- --common-opt

== Customizations in spec ==
Generated spec files by specify will have many placeholders for customizations,
such as:

# >> build pre
# << build pre

You can add any custom code between the markers, next time when you run
``specify``, the text between the markers will be kept as is, all other sections
relying on the meta data from the YAML file will be changed depending on the
values in the YAML file.

The following placeholders in spec can be customized:

* Private Macros, used in this package's spec

With placeholder:
# >> macros
# << macros

* Extra setup scripts in the last of ``%prep``

With placeholder:
# >> setup
# << setup

* Pre-Build, scripts before package building

With placeholder:
# >> build pre
# << build pre

* Post-Build, scripts after package building

With placeholder:
# >> build post
# << build post

* Pre-Install, scripts before package installation

With placeholder:
# >> install pre
# << install pre

* Post-Install, scripts after package installation

With placeholder:
# >> install post
# << install post

* Files, files list in packaged rpm

With placeholder:
# >> files [sub-package]
# << files [sub-package]
NOTE**: "sub-packge" stands for the name of sub-package, and it is optional. If no sub-package name specified, it means the files of **main** package.
NOTE**: If the file list is simple enough, you can use YAML *Files* keyword instead to record it.

* Scriptlets for %check section

With placeholder:
# >> check
# << check
NOTE**: Only if YAML boolean *Check* is specifed as ``yes``, %check with placeholder lines will be generated in .spec.

* Scriptlets for %pre section

With placeholder:
# >> pre
# << pre
NOTE**: The placeholder lines will NOT generated in spec by default. If you need customized %pre scripts, it need be added manually, and only once.

* Scriptlets for %preun section

With placeholder:
# >> preun
# << preun
NOTE**: The placeholder lines will NOT generated in spec by default. If you need customized %preun scripts, it need be added manually, and only once.

* Scriptlets for %post section

With placeholder:
# >> post
# << post
NOTE**: The placeholder lines will NOT generated in spec by default. If you need customized %post scripts, it need be added manually, and only once.

* Scriptlets for %postun section

With placeholder:
# >> postun
# << postun
NOTE**: The placeholder lines will NOT generated in spec by default. If you need customized %postun scripts, it need be added manually, and only once.

== Internal Implementation ==
Spectacle uses cheetah templates to generate the spec file, based the metadata
from YAML file. But the end users need not tackle it.

== Tips ==
To upgrade the pkg to a newer version, you can just edit the
version string in spectacle YAML file, and when you run ``specify``, it
will download the needed files for you automatically.

For packages with locale data, *LocaleName* is needed. If package
maintainers cannot confirm whether there are locale files, they can just
do not use *LocaleName* at first, and whenever "unpackaged files" rpm
packaging errors encountered, it means *LocaleName* should be added. And
please do not use it for packages without locale data to keep them clean,
though it will not block the building and packaging.

When using spec2spectacle/ini2spectacle to generate spectacle, the following problems should be checked:
* Remove duplicate Requires(include pre/post/preun/postun) which were added automatically based on the analysis of file list.
* Review and clean up the reserved scripts in "build|install pre|post" sections in new generated spec file.

User can use "series.conf" file to specify multiple patches under package directory. The "series.conf" can be used by ``quilt`` and the content can be updated to spec automatically when running ``specify``.

When you use ``specify`` to update a .spec file, any %changelog section will be removed in total. This is because the [[Packaging/Guidelines|Packaging Guidelines]] require using *.changes files instead of an explicit %changelog section in your .spec. (And spectacle doesn't have any changelog support for the .yaml file.) Before rebuilding a package, OBS will add the .changes file to the end of the .spec. (So, if you're building packages without OBS/osc, then you will need to do this manually.)

Spectacle

2011-03-25T17:29:02Z

Gabrbedd: Add information about how spectacle updates the .spec file

Meego handset on netbook

2011-03-17T02:30:25Z

Gabrbedd: Add link to actual information. :-)

See [[MeeGo_Desktop/Changing_Desktops]]

MeeGo Conference Spring 2011/Session ideas

2011-03-10T00:40:43Z

Gabrbedd: Add session ideas concerning MeeGo Compliance

= We need your ideas! =

What would '''you''' like to see at the conference? What is something that you would be interested in attending? Please add your idea to this list. You don't need to be a technical expert or anything. The experts will come to this page looking for ideas.

To edit this page, you need to log in (or register) using the link at the top of the page. After you are logged in, an "edit" button will appear.

= Ideas for sessions =

* ARM discussion forum
* Writing and Packaging apps for MeeGo Compliance
* Verifying MeeGo Compliance for Applications
* Verifying MeeGo Compliance for Distributions/Systems/Devices

* '''''Add your idea here'''''

MeeGo Conference Spring 2011/Session ideas

2011-03-08T18:09:18Z

Gabrbedd: Add an intro inviting people to add ideas

Build Infrastructure/Community Builder/ITP

2011-03-05T18:00:28Z

Gabrbedd: Add QJackCtl

== Outline ==

Listed on this page are packages and applications started/completed within the community.
If you have a package you are trying to port, please add it here.

For general requests for new packages, please see the thread here:
http://forum.meego.com/showthread.php?t=2020

== Package list ==

Please keep in alphabetical order

Package Name

= A =
* aiccu - [http://repo.pub.meego.com/home:/earthling/meego_1.1_extras/ earthling:home] (done)

= B =

= C =

= D =

= E =
* Enna - [http://repo.pub.meego.com/home:/arfoll:/enna/meego_1.1_core/ arfoll:home] (done)
* eboard

= F =
* fceux : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)
* ffmpeg : [http://repo.pub.meego.com/home:/arfoll:/enna/meego_1.1_core/ arfoll:home] (done)

= G =

= H =

= I =

= J =

* JACK Audio Connection Kit (http://jackaudio.org) - a system for handling real-time, low latency audio (and MIDI). Recommend using Jack2 with dbus-only support because it integrates well with pulseaudio. Setting up JACK isn't exactly straightforward, so please ping gabrbedd@gmail.com .

= K =

= L =

* libgda4 [http://repo.pub.meego.com/home:/piotras/meego_1.1_extras_Netbook/ piotras:home] (done)
* liblo (http://liblo.sourceforge.net/) - Lightweight implementation of Open Sound Control protocol.
* libqscintilla [http://repo.pub.meego.com/home:/earthling/meego_1.1_extras/ earthling:home] (done - no Qt3, no Python)
* Liqbook : Sketch Font and Smile proposal. A digital love affair with the written word.
** on maemo servers http://maemo.org/packages/view/liqbook/
** tested on ideapad running handset and netbook UX.
** Screenshot: http://liqbase.net/liq.20110208_002.liqbook.on.meego.ideapad.jpg

= M =

* midgard2-core : [http://repo.pub.meego.com//home:/piotras:/midgard2/meego_1.1_extras/ piotras:home:midgard2](done)
* mercurial : [http://repo.pub.meego.com/home:/arfoll:/utils/meego_1.1_core/ arfoll:home] (done)

= N =

= O =

= P =

* PHP5
* python-midgard2 : [http://repo.pub.meego.com//home:/piotras:/midgard2/meego_1.1_extras/ piotras:home:midgard2](done)
* Puzzle-master : Maemo game created in community by Venemo
** on maemo servers http://repository.maemo.org/extras-devel/pool/fremantle/free/source/p/puzzle-master/puzzle-master_1.0.0.tar.gz
** quickly tested on ideapad and nice touch interactive game :)
** now with git repo too http://gitorious.org/colorful-apps/puzzle-master

= Q =

* QJackCtl (http://qjackctl.sourceforge.net/) - a GUI front-end for the JACK Audio Connection Kit. Depends on the ITP for JACK (above).

= R =

= S =

* Scummvm : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)
* scummvm-tools : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)

= T =
* tint2 - package was previosuly blocked by imlib2 not building on maemo OBS. Now it builds i'll do this :-)
* Tomboy

= U =

= V =

= W =

= X =

* x11vnc : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)
* xchat : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)
* xournal : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)

= Y =

= Z =

Build Infrastructure/Community Builder/ITP

2011-03-05T17:58:51Z

Gabrbedd: add JACK audio connection kit

== Outline ==

Listed on this page are packages and applications started/completed within the community.
If you have a package you are trying to port, please add it here.

For general requests for new packages, please see the thread here:
http://forum.meego.com/showthread.php?t=2020

== Package list ==

Please keep in alphabetical order

Package Name

= A =
* aiccu - [http://repo.pub.meego.com/home:/earthling/meego_1.1_extras/ earthling:home] (done)

= B =

= C =

= D =

= E =
* Enna - [http://repo.pub.meego.com/home:/arfoll:/enna/meego_1.1_core/ arfoll:home] (done)
* eboard

= F =
* fceux : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)
* ffmpeg : [http://repo.pub.meego.com/home:/arfoll:/enna/meego_1.1_core/ arfoll:home] (done)

= G =

= H =

= I =

= J =

* JACK Audio Connection Kit (http://jackaudio.org) - a system for handling real-time, low latency audio (and MIDI). Recommend using Jack2 with dbus-only support because it integrates well with pulseaudio. Setting up JACK isn't exactly straightforward, so please ping gabrbedd@gmail.com .

= K =

= L =

* libgda4 [http://repo.pub.meego.com/home:/piotras/meego_1.1_extras_Netbook/ piotras:home] (done)
* liblo (http://liblo.sourceforge.net/) - Lightweight implementation of Open Sound Control protocol.
* libqscintilla [http://repo.pub.meego.com/home:/earthling/meego_1.1_extras/ earthling:home] (done - no Qt3, no Python)
* Liqbook : Sketch Font and Smile proposal. A digital love affair with the written word.
** on maemo servers http://maemo.org/packages/view/liqbook/
** tested on ideapad running handset and netbook UX.
** Screenshot: http://liqbase.net/liq.20110208_002.liqbook.on.meego.ideapad.jpg

= M =

* midgard2-core : [http://repo.pub.meego.com//home:/piotras:/midgard2/meego_1.1_extras/ piotras:home:midgard2](done)
* mercurial : [http://repo.pub.meego.com/home:/arfoll:/utils/meego_1.1_core/ arfoll:home] (done)

= N =

= O =

= P =

* PHP5
* python-midgard2 : [http://repo.pub.meego.com//home:/piotras:/midgard2/meego_1.1_extras/ piotras:home:midgard2](done)
* Puzzle-master : Maemo game created in community by Venemo
** on maemo servers http://repository.maemo.org/extras-devel/pool/fremantle/free/source/p/puzzle-master/puzzle-master_1.0.0.tar.gz
** quickly tested on ideapad and nice touch interactive game :)
** now with git repo too http://gitorious.org/colorful-apps/puzzle-master

= Q =

= R =

= S =

* Scummvm : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)
* scummvm-tools : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)

= T =
* tint2 - package was previosuly blocked by imlib2 not building on maemo OBS. Now it builds i'll do this :-)
* Tomboy

= U =

= V =

= W =

= X =

* x11vnc : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)
* xchat : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)
* xournal : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)

= Y =

= Z =

Build Infrastructure/Community Builder/ITP

2011-03-05T17:55:32Z

Gabrbedd: add ITP for liblo

== Outline ==

Listed on this page are packages and applications started/completed within the community.
If you have a package you are trying to port, please add it here.

For general requests for new packages, please see the thread here:
http://forum.meego.com/showthread.php?t=2020

== Package list ==

Please keep in alphabetical order

Package Name

= A =
* aiccu - [http://repo.pub.meego.com/home:/earthling/meego_1.1_extras/ earthling:home] (done)

= B =

= C =

= D =

= E =
* Enna - [http://repo.pub.meego.com/home:/arfoll:/enna/meego_1.1_core/ arfoll:home] (done)
* eboard

= F =
* fceux : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)
* ffmpeg : [http://repo.pub.meego.com/home:/arfoll:/enna/meego_1.1_core/ arfoll:home] (done)

= G =

= H =

= I =

= J =

= K =

= L =

* libgda4 [http://repo.pub.meego.com/home:/piotras/meego_1.1_extras_Netbook/ piotras:home] (done)
* liblo (http://liblo.sourceforge.net/) - Lightweight implementation of Open Sound Control protocol.
* libqscintilla [http://repo.pub.meego.com/home:/earthling/meego_1.1_extras/ earthling:home] (done - no Qt3, no Python)
* Liqbook : Sketch Font and Smile proposal. A digital love affair with the written word.
** on maemo servers http://maemo.org/packages/view/liqbook/
** tested on ideapad running handset and netbook UX.
** Screenshot: http://liqbase.net/liq.20110208_002.liqbook.on.meego.ideapad.jpg

= M =

* midgard2-core : [http://repo.pub.meego.com//home:/piotras:/midgard2/meego_1.1_extras/ piotras:home:midgard2](done)
* mercurial : [http://repo.pub.meego.com/home:/arfoll:/utils/meego_1.1_core/ arfoll:home] (done)

= N =

= O =

= P =

* PHP5
* python-midgard2 : [http://repo.pub.meego.com//home:/piotras:/midgard2/meego_1.1_extras/ piotras:home:midgard2](done)
* Puzzle-master : Maemo game created in community by Venemo
** on maemo servers http://repository.maemo.org/extras-devel/pool/fremantle/free/source/p/puzzle-master/puzzle-master_1.0.0.tar.gz
** quickly tested on ideapad and nice touch interactive game :)
** now with git repo too http://gitorious.org/colorful-apps/puzzle-master

= Q =

= R =

= S =

* Scummvm : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)
* scummvm-tools : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)

= T =
* tint2 - package was previosuly blocked by imlib2 not building on maemo OBS. Now it builds i'll do this :-)
* Tomboy

= U =

= V =

= W =

= X =

* x11vnc : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)
* xchat : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)
* xournal : [http://repo.pub.meego.com/home:/timoph/meego_1.1_extras_Netbook/ timoph:home] (done)

= Y =

= Z =

Using MeeGo with the Windows 7 Boot Loader

2011-03-05T06:25:05Z

Gabrbedd: Booting MeeGo with the Windows boot loader, brought to you by two weeks of frustration

Starting with Windows Vista, Microsoft includes a more advanced boot loader with their OS. Getting this boot loader to work with MeeGo can be a little tricky, because the extlinux boot loader is really intended for embedded set-ups (not flexible, multi-os desktops).

===Set up the Partitions===
Before you do anything, you must have your partitioning planned out in advance. Once you start, you must not change it. You will need:

#A 200 MB ext3 partition (will be MeeGo's /boot)
#A 2GB swap partition
#A btrfs partition at least 10GB (will be MeeGo's /)

Do not modify the "boot flag."

If you need to resize an NTFS partition, or if you need to preserve a partition (or two) at the /end/ of the drive... it is strongly recommended that you do this with a Linux LiveCD (esp. an Ubuntu or Fedora install CD). MeeGo can not resize partitions, and the graphical partition manager is unstable in this situation.

Many OS's do not yet have support for the btrfs file system, so just select ext3.

Write down the partitions that you created (e.g. sda5 is /boot, sda6 is /, sda7 is swap).

===Save the Windows MBR===

After you have partitioned, you must save the windows MBR (with partition table). This can be done from any Linux Live CD (even MeeGo):

dd if=/dev/sda of=/tmp/windows_mbr.bin bs=512 count=1

Save this on an external drive.

===Install MeeGo===

Install MeeGo. At the disk partitioning step, select "Custom Layout." Configure the devices as shown above. Be sure that you instruct MeeGo to (re)-format each of these partitions. Make sure that MeeGo's / is using a btrfs file system.

===Grab the MeeGo MBR and Restore the Windows MBR===

After MeeGo is installed, do /not/ reboot. Shut down and boot into a live OS so that you can grab MeeGo's MBR.

dd if=/dev/sda of=/tmp/meego_mbr.bin bs=512 count=1

Also save this on an external drive.

Now, restore the windows MBR:

dd if=/path/to/windows_mbr.bin of=/dev/sda

When you reboot, it will take you to windows. Windows may offer to boot in "safe mode," but choose to start windows normally.

===Add MeeGo to the Windows Boot Loader===
Boot into windows. Open up a Command Prompt as the administrator. Copy meego_mbr.bin to C:\. Fire off BCDEdit commands until you have this setup:

Real-mode Boot Sector
---------------------
identifier {f4019350-9104-11df-9aaf-fcea12ecf137}
device partition=C:
path \meego_mbr.bin
description Transmission 5 (MeeGo)

Note that the GUID ("{f4019...137}") will be different. See [http://www.justlinux.com/forum/archive/index.php/t-150601.html this article] for a step-by-step on entering the BCDEdit commands. Note that step 2 in that document should probably end with "device partition=C:" instead of "device boot".

On your next reboot, Windows will let you select which OS to run... and both should load fine.

Installation of MeeGo on notebook

2011-03-05T05:50:58Z

Gabrbedd: Add link to instructions on Win7 boot loader

This page lists down installation steps followed for Toshiba Satellite U305-S5077, Dell Latitude E6400, Wipro WNB7PBC4830R. The systems had Ubuntu 10.04 and Windows installed prior to MeeGo installation (MeeGo was installed as 3rd OS)

General MeeGo installation steps can be found in http://meego.com/downloads/releases/1.1/meego-v1.1-netbooks. This page focusses on some troubleshooting steps for installing MeeGo on laptops and assumes that the reader is familiar with general MeeGo installation steps illustrated in http://meego.com/downloads/releases/1.1/meego-v1.1-netbooks.

===Creating the installation medium===
#Download the live image from http://meego.com/downloads/releases/netbook or http://repo.meego.com. It could be a stable release or a development release.
#If burning to a USB stick, byte copy the image to the USB stick. Linux users, you can use 'dd' for this. Windows users, download and use Win32DiskImager program for this.
#Some laptops do not recognize this image burned on a USB stick as a USB drive during boot. The reason is that some BIOSes have a size above which a USB disk is not recognized as a USB disk. Usually it is 500MB, but in some cases it is higher. One specific case is the Wipro BC4830R model laptop with Intel i3 processor. In this case, the laptop recognizes the disk as a floppy disk and cannot boot using the USB disk.
#To overcome the issue in step 3, write the downloaded image to a DVD. Linux users can use Brasero to burn the image to a DVD, Windows users can use ImgBurn.
#Some laptops do not boot well when the image is burned to a DVD-RW. They seem to have some issue booting from such a DVD. Case in point is the Wipro BC4830R model. So, to be on the safe side, write the image to a DVD-R disk.
#Be warned that booting and installing from DVD is much slower compared to booting and installing from USB disk.

===Preparing your laptop for the installation===
If you are installing on a clean laptop which has no other OS, skip this section and proceed to the next section
#If you want to install MeeGo alongside Windows, follow these steps. If you already have free space of at least 4GB on your disk (not free space in a partition but free space on the disk), skip the following steps on partitioning. If you do not have free space of 4GB on the disk, use the following steps to create free space.
##If you do not have Windows 7 or Windows Vista installation / rescue disk, create a GParted live CD first. Download the GParted live CD image and burn to a CD. Defrag your hard disk.
##Boot from the GParted Live CD now and use it to resize an existing partition to gain at least 4GB free space.
##If you have Windows 7 or Windows Vista installation / rescue disk, boot using the installation / rescue disk, choose the rescue option and choose to enter at command prompt.
##At the command prompt, use the DISKPART command and resize the partition that you want to shrink and gain space from. Use the command 'shrink querymax' to see how much space you can gain.
##If you want 4GB space, use the command 'shrink desired=4096'
#If you want to install MeeGo alongside Linux (such as Ubuntu), and do not have free space, use GParted to reclaim space as outlined above in step 1.

===Installing Meego===
Now that you have the required free space, let's install Meego.
#Insert the USB disk / DVD-R and boot the system.
#Follow the instructions on screen. It is better to follow defaults and create 3 partitions for /boot, / and swap as suggested by installation steps.
#On one laptop, in which root file system which was formatted as btrfs failed after some days. It was reinstalled with root file system as ext3.
#At the end of installation, Meego will ask which OS you want as default if another OS is installed. Any choice you make here is immaterial as you will have to manually edit the boot configuration file to get the correct choice.
#Reboot the system. If MeeGo is your only OS, proceed to the next section. If you have another OS and want to dual boot properly, see the following steps.
#You will notice that even if you chose another system as the default, Meego boots automatically without showing any choice.
#Boot into Meego. Launch the 'terminal' application and execute the following commands:
##sudo su
##Enter password when prompted
##gedit /boot/extlinux/extlinux.conf&
#In this file, make the following modifications:
##The line where it says timeout, change the timeout value to 100. This gives you 10 seconds to choose an OS.
##The line where it says ontimeout meego, change it to ontimeout <labelname of other os> if you want to boot other OS on timeout
##Under the section 'label meego', remove the line 'menu default' and add 'menu default' to other OS entry if you want other OS to be highlighted by default
#That is it, save the file and reboot. You should see boot options correctly now.
#Boot into Meego and other OS to make sure that you are able to dual boot fine.
#In some cases where Windows is the other OS, if you choose to boot Windows, you will get a message that bootloader cannot be found. It could just be that Windows is on another volume and not the volume that Meego thought it was. Under the section for Windows in extlinux.conf, you will find a line 'append boot 1'. Try and change that to 2 or 3 and see if Windows boots. This happened with a Toshiba Satellite and setting it to 2 worked.

===Using another bootloader===
#If you have already installed Ubuntu on your system or another Linux OS and want to use the bootloader of that OS, the bad news is that Meego will overwrite it. The good news is that you can fix this.
#If you have Ubuntu already installed, chances are that you are using GRUB or GRUB2. Use the Ubuntu installation CD (desktop or alternate) to boot, choose to rescue a broken system.
#You will get an option to reinstall GRUB / GRUB2. Choose this option and GRUB will be reinstalled and it will also add an entry for Meego. This entry though will show up as 'Unknown Linux'.
#If you were already booting Windows along with Ubuntu using GRUB, reinstalling GRUB will give you the option to boot Windows, Ubuntu and Meego. This has been tried and tested successfully on Wipro BC4830R laptop.
#If you wish to use the boot loader that comes with Windows Vista and Windows 7 (and later), please see [[Using MeeGo with the Windows 7 Boot Loader]].

===Wireless Drivers===
#Some laptops come with Broadcom wireless cards (Dell Latitude E6400) and some come with RealTek RTL 8192 (8191SE) wireless cards. These wireless cards do not work out of the box. You will need to use wired connection till you can get your wireless working. Follow these instructions to get your wireless working.
#For Broadcom cards, use Slaine's instructions from the site: http://slaine.org/_slaine/Meego_1.0_Wifi.html
#For RealTek RTL 8192 (8191SE) cards, follow these instructions.
##Download the driver source code from RealTek's site: http://www.realtek.com.tw/downloads/downloadsView.aspx?id=1&PNid=21&PFid=48&Level=5&Conn=4&ProdID=226&DownTypeID=3&GetDown=false&Downloads=true
##If that link does not work, go to www.realtek.co.tw, choose the product 'Communication Network ICs', choose the sub product Wireless LAN IC, WLAN NIC, IEEE802.11 b/g/n single chip. Go to the download section and download the relevant source for your card.
##To determine your card, run the command 'lspci' in the console.
##Once the source is downloaded, unpack the contents to a folder.
##Download and install gcc, make and kernel-netbook-devel from software catalogs. You may have to enable the source catalogs to install kernel-netbook-devel.
##Open terminal and execute the following commands:
##*sudo su (enter password when prompted)
##*cd /[path to folder where realtek source was unpacked]
##*make
##*make install
##*Reboot your machine and wireless should be working

===Other information===
On all the laptops (Wipro BC4830R, Dell E6400 Latitude, Toshiba Satellite U305-S5077), devices such as integrated webcam, bluetooth, mike etc worked out of the box. On the Wipro laptop, the wireless key (Fn+F10) had no effect on wireless state (it was always on) though the keys for camera, Bluetooth worked

Tips on compiling and packaging kernels in MeeGo

2011-02-17T05:29:27Z

Gabrbedd: Create page with info that was first posted to ML

== Summary ==

This page contains instructions and tips for those who want to compile their own kernel. This includes obtaining sources, unpacking, patching, configuring, compiling, installing, and packaging a kernel. To this end, there are two main work-flows:

# For those debugging, writing drivers, or experimenting
# For those packaging kernels to be included in a MeeGo distribution

These work-flows tend to be completely different... but both are covered in this document. A few other typical cases (debug symbols, out-of-tree modules) are also covered.

Note that all the examples here will use the (now obsolete) `kernel-netbook` package as an example. Please substitute the name of the kernel package you're working with. To figure out which one you're currently running, this command will tell you:

$ rpm -qf /boot/vmlinuz-$(uname -r)

== Installing debug symbols ==

If you simply want debugging symbols, you need only install the `debuginfo` package. You will typically have to enable the `debug` repository, first. For example:

$ sudo zypper mr --enable core-debuginfo
$ sudo zypper install kernel-netbook-debuginfo

That's it.

== Installing headers for building an out-of-tree module ==

If you have an out-of-tree kernel module that you need to build, you need to install the `devel` package for that kernel, as well as any compiler tools:

$ sudo zypper install rpmdevtools pattern:development-tools
$ sudo zypper install kernel-netbook-devel

This installs the kernel headers that you need in order to build your module. Now refer to the instructions that came with the module.

== Locally Compiling a Kernel (not packaging) ==

These instructions are for those who simply wish to compile a kernel and install it (without concern for package management, MeeGo compliance, etc.). These instructions aren't particular to MeeGo, except for obtaining the sources.

First, make sure that you have the source repositories enabled.

$ sudo zypper mr --enable core-source

Next, grab the source RPM from the repository. We're also installing the `quilt` utility. Note that this shows the `kernel-netbook` package. You will need to substitute the name of the kernel you wish to use as a starting point.

$ sudo zypper install quilt
$ sudo zypper si kernel-netbook

Now create a `sandbox` folder for unpacking the source RPM.

$ mkdir sandbox/
$ cd sandbox/
$ rpm2cpio ~/rpmbuild/SRPMS/kernel-netbook-2.6.35.3-12.1.src.rpm | cpio -id --no-absolute-filenames

Inside this folder, you now have all the sources that were used to compile the kernel. This includes the original tarball released at kernel.org, all patches, rpm spec files, etc. Unpacking the kernel is done like this:

$ tar xjf linux-2.6.35.tar.bz2

To patch the kernel, note that there is a file called `series` in the current directory. This can be used by a program called `quilt` to patch (and un-patch) a series of patches to a source tree. To use it, you need to set the environment variable "QUILT_PATCHES" to point to the location of the `series` file.

$ cd ../linux-2.6.35
$ export QUILT_PATCHES=..
$ quilt push -a

Now, compile and configure the kernel like normal (in this case, copying the config from the current kernel):

$ cp /boot/config-2.6.35.3-12.1-netbook .config
$ make menuconfig
$ make -j3
$ sudo make modules_install && sudo make install

Note that `make install` understands how to manipulate the extlinux boot loader, so there's no extra steps to configure the boot loader.

Now reboot to try the new kernel:

$ sudo shutdown -r now

If you wish to work on your own kernel patch set, you will probably want to learn to use git or quilt for this sort of work. Both are available within MeeGo.

== Packaging a Kernel for MeeGo ==

The instructions above are simple and productive for development. When you wish to package a custom version of the kernel, you must be more careful to consider [[Quality/Compliance|MeeGo Compliance]]. Also, it's best to match the current work-flow of the core kernel developer team. Since this workflow is constantly being adjusted to the needs of that team, your best resource is:

* The [http://meego.gitorious.org/meego-os-base/kernel-source kernel source]] repository (git)
* The [http://meego.gitorious.org/meego-os-base/kernel-source/blobs/devel-kernel/README.workflow README.workflow]] file in that repository

The kernel is configured by making overrides to config-generic. E.g. for an x86 target, config-generic is first read. Then config-x86 is read. Where there's a conflict with config-generic, the values in config-x86 are used. Likewise, the rpm spec files are created as override/adaptations of the kernel.spec file.

Adding patches requires that you add them to both `series` and your adaptation spec file (e.g. kernel-netbook.spec). You then use rpmbuild to package the kernel as you would any other package: copy all sources to ~/rpmbuild/SOURCES and the spec file to ~/rpmbuild/SPECS.

MeeGo kernel documentation for contributors

2011-02-17T04:30:56Z

Gabrbedd: Fix capitalization in new link.

==Configuration changes==

If you want to suggest a kernel configuration option change for MeeGo, please send an email to the [http://lists.meego.com/listinfo/meego-kernel meego-kernel mailing list] or file a bug in [http://bugs.meego.com/ bugzilla]. Please include a description of why you want the change done (not just the "what"), why it is important for MeeGo to do this change.

Note that MeeGo tries to keep the kernel configurations between the different builds as consistent as possible, and because of that, you may see configuration options that are not strictly required for some platform still be enabled. We do make exceptions to the "as consistent as possible" if a general configuration option has a significant impact on size, but we'd like to know this... (think of it this way: "Turning this option off saves 102312 bytes of size, and phones do not use fiber channel" is a pretty good justification description, while "turn FOO off for size" is not).

==Developing drivers for MeeGo==

The MeeGo project really wants Device drivers and other kernel code to be developed for, and integrated in, the [http://kernel.org kernel.org] kernel as maintained by Linus Torvalds. Every patch we carry has a cost for us, and we do not want to carry long term patches.

So if you want to develop a device driver for MeeGo, please develop your driver for, and submit your driver to, the kernel.org Linux kernel. In fact, this is a requirement for MeeGo!

Now, sometimes the process of integrating into the kernel.org kernel takes a bit of time (for example your code may be in a maintainer tree but not yet merged by Linus). In that case, and as long as you're committed to continue the upstream integration process, we may make and exception and integrate your code prior to Linus Torvalds doing the final merge of your code.

There will be a few hard cases where the upstream kernel, for principle reasons, to reject a device driver. The PowerVR graphics drivers come to mind. For those cases, for pragmatic reasons, the Meego Technical Steering Group can grant exceptions to the policy and allow such drivers into MeeGo regardless of upstream rejection. Such exception comes with a set of requirements on maintenance and responsiveness etc/etc.

== Requesting a patch from Linus' kernel, or a maintainer tree to be integrated into MeeGo==

Lets say you have developed a patch, or otherwise want a patch that Linus or a maintainer already merged (or is in progress, as described above) included into MeeGo. There are two ways to request this: Email to [http://lists.meego.com/listinfo/meego-kernel meego-kernel] and [http://bugs.meego.com MeeGo Bugzilla]. For either case, we expect you to do the same diligence you do when you send a patch to the Linux Kernel Mailing List: You provide a description of the what and the why, you format the patch in the LKML form (included [http://meego.com/about/contribution-guidelines/signed-process Signed-off-by: line] etc etc).

Specifically for MeeGo, we also want you to tell us where the patch is in the upstream integration process. If your patch is already merged by Linus, we'd like you to give us the git commit ID (we have tools that make it easy for us to backport patches based on this commit ID). If the patch is in a maintainer tree, let us know. If your patch is in progress of being merged by the maintainer, let us know where you posted it and where the review is happening.

==Additional Contribution Guidelines==

Please also read the [http://wiki.meego.com/images/Kernel_criteria.pdf kernel criteria (PDF)] document for additional requirements before submitting your contribution.

Patches sent to the mailing lists should be broken up into several email messages of less than 100KB each.

You should also consider the [[Release_Engineering|MeeGo release schedules]], including code freeze dates, before submitting your contributions.

MeeGo cannot take patches that add system calls or other userspace ABI numbers/structures without having these ABIs first merged upstream. This is to avoid MeeGo becoming ABI incompatible with Linux if/when the upstream kernel assigns different numbers/structures for the ABI or assigns different users to the numbers in the patch.

Please visit our [http://meego.com/about/contribution-guidelines general contribution guidelines] for other details and additional ways to contribute to MeeGo.

==Tips on Compiling and Packaging Kernels==

For tips on acquiring the kernel sources, patching, compiling, and packaging kernels (whether for MeeGo or for your own development), please see [[Tips_on_compiling_and_packaging_kernels_in_MeeGo|this article]].

MeeGo kernel documentation for contributors

2011-02-17T04:29:13Z

Gabrbedd: Create link to kernel hacking tips (new page).

==Configuration changes==

If you want to suggest a kernel configuration option change for MeeGo, please send an email to the [http://lists.meego.com/listinfo/meego-kernel meego-kernel mailing list] or file a bug in [http://bugs.meego.com/ bugzilla]. Please include a description of why you want the change done (not just the "what"), why it is important for MeeGo to do this change.

Note that MeeGo tries to keep the kernel configurations between the different builds as consistent as possible, and because of that, you may see configuration options that are not strictly required for some platform still be enabled. We do make exceptions to the "as consistent as possible" if a general configuration option has a significant impact on size, but we'd like to know this... (think of it this way: "Turning this option off saves 102312 bytes of size, and phones do not use fiber channel" is a pretty good justification description, while "turn FOO off for size" is not).

==Developing drivers for MeeGo==

The MeeGo project really wants Device drivers and other kernel code to be developed for, and integrated in, the [http://kernel.org kernel.org] kernel as maintained by Linus Torvalds. Every patch we carry has a cost for us, and we do not want to carry long term patches.

So if you want to develop a device driver for MeeGo, please develop your driver for, and submit your driver to, the kernel.org Linux kernel. In fact, this is a requirement for MeeGo!

Now, sometimes the process of integrating into the kernel.org kernel takes a bit of time (for example your code may be in a maintainer tree but not yet merged by Linus). In that case, and as long as you're committed to continue the upstream integration process, we may make and exception and integrate your code prior to Linus Torvalds doing the final merge of your code.

There will be a few hard cases where the upstream kernel, for principle reasons, to reject a device driver. The PowerVR graphics drivers come to mind. For those cases, for pragmatic reasons, the Meego Technical Steering Group can grant exceptions to the policy and allow such drivers into MeeGo regardless of upstream rejection. Such exception comes with a set of requirements on maintenance and responsiveness etc/etc.

== Requesting a patch from Linus' kernel, or a maintainer tree to be integrated into MeeGo==

Lets say you have developed a patch, or otherwise want a patch that Linus or a maintainer already merged (or is in progress, as described above) included into MeeGo. There are two ways to request this: Email to [http://lists.meego.com/listinfo/meego-kernel meego-kernel] and [http://bugs.meego.com MeeGo Bugzilla]. For either case, we expect you to do the same diligence you do when you send a patch to the Linux Kernel Mailing List: You provide a description of the what and the why, you format the patch in the LKML form (included [http://meego.com/about/contribution-guidelines/signed-process Signed-off-by: line] etc etc).

Specifically for MeeGo, we also want you to tell us where the patch is in the upstream integration process. If your patch is already merged by Linus, we'd like you to give us the git commit ID (we have tools that make it easy for us to backport patches based on this commit ID). If the patch is in a maintainer tree, let us know. If your patch is in progress of being merged by the maintainer, let us know where you posted it and where the review is happening.

==Additional Contribution Guidelines==

Please also read the [http://wiki.meego.com/images/Kernel_criteria.pdf kernel criteria (PDF)] document for additional requirements before submitting your contribution.

Patches sent to the mailing lists should be broken up into several email messages of less than 100KB each.

You should also consider the [[Release_Engineering|MeeGo release schedules]], including code freeze dates, before submitting your contributions.

MeeGo cannot take patches that add system calls or other userspace ABI numbers/structures without having these ABIs first merged upstream. This is to avoid MeeGo becoming ABI incompatible with Linux if/when the upstream kernel assigns different numbers/structures for the ABI or assigns different users to the numbers in the patch.

Please visit our [http://meego.com/about/contribution-guidelines general contribution guidelines] for other details and additional ways to contribute to MeeGo.

==Tips on Compiling and Packaging Kernels==

For tips on acquiring the kernel sources, patching, compiling, and packaging kernels (whether for MeeGo or for your own development), please see [[tips_on_compiling_and_packaging_kernels_for_meego|this article]].

Image Creation

2011-02-06T22:47:48Z

Gabrbedd: Add advanced hacking tips on meta-packages, patterns, and repository 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 something called "MIC2" (for distinguishing 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 10 and above)
** Opensuse (> OpenSUSE 11.1)
** and Ubuntu > 9.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 be able to use MIC2, your host machine to run mic2 must have Intel(r) Atom(tm) or Intel(r) Core(tm) 2 CPU (support for SSSE3), this is a hard requirement (ARM image is exceptional), the following packages must be available on your system. (Most of the packages are installed by default, depending on the distribution.):

* yum
* rpm
* kpartx
* parted
* syslinux
* isomd5sum
* kvm
* zlib-devel(for compiling)
* python-devel(for installation)

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

* squashfs
* squashfs-tools
* dm_snapshot
* loop

Specific packages for Fedora:

* pykickstart
* device-mapper

Specific packages for Ubuntu 8.10:

* python-celementtree
* python-elementtree
* dmsetup

=== Installing requirements for Ubuntu 10.04 ===

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 11, Fedora 12, Ubuntu 9.10, Ubuntu 10.04, OpenSUSE 11.1, OpenSUSE 11.2, 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 11, Fedora 12 and Fedora 13'''

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 11, Fedora 12 and Fedora 13'''

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

<pre>
# yum update mic2
</pre>

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

1. Add package source

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

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

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.04:
:wget http://repo.meego.com/MeeGo/tools/repos/ubuntu/10.04/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.1, OpenSUSE 11.2 and OpenSUSE 11.3'''

1. Add repos

For OpenSUSE 11.1:

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

For OpenSUSE 11.2:

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

For OpenSUSE 11.3:

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

2. sudo zypper install mic2

* '''Update Steps For OpenSUSE 11.1, OpenSUSE 11.2 and OpenSUSE 11.3'''

<pre>
sudo zypper update 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.

== 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.

To obtain the official Meego .ks files, go here: TO-DO-LINK

'''Create ARMv7 Images'''

When creating images for ARMv7 hardware, pass ''--arch=armv7l'' 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.0-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.0-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.0-default-XX-sda.bin of= meego-1.0-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.0-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.0-default-XX.img is created. You can use below to mount it and chroot into it.

<pre>
sudo mount -o loop meego-1.0-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.0-default-XX folder with a meego-1.0-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.0-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.0-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.0-default-XX folder with both meego-1.0-default-XX-sda.vmdk image and meego-1.0-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) ===

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:

*For ARM based Nokia N900: http://repo.meego.com/MeeGo/builds/trunk/ <version>/handset/images/meego-handset-armv7l-n900/
*For Intel Atom based netbook and handset (Moorestown): http://repo.meego.com/MeeGo/builds/trunk/ <version>/{netbook,handset,ivi}/images/<respective directory>/

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.

====Modifying 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>

====Proxy settings for the repos in .ks====

An option you might find useful if you're behind a firewall is the --proxy flag for the "repo" definition. You can specify it in the .ks as follows:

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

If you are behind a firewall, you don't need to set proxyuser and proxypasswd, like:

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

'''Note:''' You can also insert this in your sudoers config:

<pre>
$ sudo visudo

Add: Defaults env_keep += " no_proxy http_proxy ........."
</pre>
so sudo will adhere to the no_proxy and proxy settings.

=== 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/devel/trunk/repo/ia32/os/ -o /your/final/bootstrap
</pre>

-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.

= 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. In order to run it correctly, you can only keep just 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 occues when trying to build ARM images without passing ''--arch=armv7l'' to ''meego-image-creator''.

===Proxy cache===

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

Some servers (e.g. 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 an 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 ensure you have a stable & latest kernel and btrfs-progs 0.19 on your system, this needs you 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 ensure 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.

Maliit/MeeGo 1.1

2010-11-23T04:20:50Z

Gabrbedd: Minor formatting improvements. Add info on making the keyboard reapper.

= Handset =
Virtual keyboard works in handset UX except in N900 where there is something blocks the touchscreen usage together with the virtual keyboard.

= Netbook =
In order to get virtual keyboard on netbook UX, you need to do the following:
* Enable the 'handset' repository. For example:

$ sudo zypper addrepo <nowiki>http://repo.meego.com/MeeGo/releases/1.1/handset/repos/ia32/packages/</nowiki> handset
$ sudo zypper refresh

* Install these packages: meegotouch-inputmethodbridges, meegotouch-inputmethodkeyboard.
* Modify /etc/xdg/autostart/meego-im-uiserver.desktop to look like this:

[Desktop Entry]
Exec=/usr/bin/meego-im-uiserver -target slate -bypass-wm-hint
X-Moblin-Priority=High
OnlyShowIn=X-MEEGO-HS;X-MEEGO-NB

This will work with 1024x600 resolution. Replace 'slate' with other code if you have different resolution. See /etc/meegotouch/devices.conf for different codes.
* Relogin (or reboot) to desktop

Any time you activate text entry, virtual keyboard will popup with special known features:
* A horizontal swipe gesture on the keyboard will change the keyboard layout.
* ENTER key is under space (shift-space)
* ENTER doesn't work in Chromium url bar (but it works on web pages)
* text entry doesn't relocate when virtual keyboard is up, so you need to manually scroll the application
* Swipe down on the keyboard closes it
* Touching the top of the window brings the keyboard back
* Multitouch keyboard can be enabled by doing this on console: "<code>gconftool-2 -t bool -s /meegotouch/inputmethods/multitouch/enable true</code>". With it you can type upper case letters (and ENTER) by holding Shift key. Note that the gesture might go flakey, try with double finger swipe to overcome.