<?xml version="1.0"?>
<?xml-stylesheet type="text/css" href="http://wiki.meego.com/skins/common/feed.css?270"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>http://wiki.meego.com/index.php?title=Special:Contributions/Jfding&amp;feed=atom&amp;limit=50&amp;target=Jfding&amp;year=&amp;month=</id>
		<title>MeeGo wiki - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="http://wiki.meego.com/index.php?title=Special:Contributions/Jfding&amp;feed=atom&amp;limit=50&amp;target=Jfding&amp;year=&amp;month="/>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Special:Contributions/Jfding"/>
		<updated>2013-05-19T12:24:21Z</updated>
		<subtitle>From MeeGo wiki</subtitle>
		<generator>MediaWiki 1.16.2</generator>

	<entry>
		<id>http://wiki.meego.com/Release_Engineering/Plans/1.2</id>
		<title>Release Engineering/Plans/1.2</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Release_Engineering/Plans/1.2"/>
				<updated>2011-07-28T20:38:20Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* MeeGo 1.2 Release Plan by Date */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== MeeGo 1.2 Release Plan (1.2.0, 1.2.1) ==&lt;br /&gt;
&lt;br /&gt;
[[File:MeeGoReleaseTimeline1.2.x.jpg]]&lt;br /&gt;
&lt;br /&gt;
=== Detailed summary ===&lt;br /&gt;
&lt;br /&gt;
1.2.0 will be branched on May-01-2011 and released on May-19-2011.  &lt;br /&gt;
&lt;br /&gt;
1.2 will keep moving forward towards the 1.2.1 release. &lt;br /&gt;
&lt;br /&gt;
1.2.0-Updates will be cherry-picked by the Meego Update team from the 1.2 Branch into 1.2.0.Updates.&lt;br /&gt;
&lt;br /&gt;
1.2.1 will be branched around Aug-10-2011 and released around Sep-01-2011.  The release will include the MeeGo Repos and Tablet 1.2.1 images.&lt;br /&gt;
&lt;br /&gt;
1.2.1-Updates will then be cherry-picked by the Meego Update team from the 1.3 Branch into 1.2.1.Updates.  At this point, 1.2.0.Updates will also be cherry-picked by the Meego update team.&lt;br /&gt;
&lt;br /&gt;
1.2.1 will be the end of the 1.2-based releases.&lt;br /&gt;
&lt;br /&gt;
=== FAQ ===&lt;br /&gt;
&lt;br /&gt;
''Note: for all responses below, any 'oss' project always has an equivalent 'non-oss' project associated with it.''&lt;br /&gt;
&lt;br /&gt;
'''I am a developer, where do I submit my changes to be included in the 1.2.1 release?'''&lt;br /&gt;
&lt;br /&gt;
* MeeGo:1.2:oss:Testing. &lt;br /&gt;
&lt;br /&gt;
'''I am a developer, where do I submit my changes to be included in the 1.2.0-Updates?'''&lt;br /&gt;
&lt;br /&gt;
Before 1.2.1 is released, you need to submit your changes to ''both'' the 1.2 main branch project as well as the 1.2.0-Updates project.&lt;br /&gt;
&lt;br /&gt;
So both:&lt;br /&gt;
&lt;br /&gt;
* MeeGo:1.2:oss:Testing&lt;br /&gt;
&lt;br /&gt;
* MeeGo:1.2.0:oss:Update:Testing&lt;br /&gt;
&lt;br /&gt;
The reason is so that your change is also included in the future 1.2.1 release.&lt;br /&gt;
&lt;br /&gt;
After 1.2.1 is released, you will submit your changes just to:&lt;br /&gt;
&lt;br /&gt;
* MeeGo:1.2.0:oss:Update:Testing&lt;br /&gt;
&lt;br /&gt;
'''I am a developer, where do I submit my changes to be included in the 1.2.1-Updates after 1.2.1 is released?'''&lt;br /&gt;
&lt;br /&gt;
When 1.2.1 is released, there will be projects created called:&lt;br /&gt;
&lt;br /&gt;
* MeeGo:1.2.1:oss:Update&lt;br /&gt;
* MeeGo:1.2.1:oss:Update:Testing&lt;br /&gt;
&lt;br /&gt;
This is where you will submit those changes targeting 1.2.1-Update.  If your change is also targeting 1.2.0-Update, you should also submit to that project as well (MeeGo:1.2.0:oss:Update:Testing).&lt;br /&gt;
&lt;br /&gt;
'''Where can I get a quick reference list of repositories and OBS projects used for MeeGo?'''&lt;br /&gt;
&lt;br /&gt;
* [[Release_Engineering/Repo_List|MeeGo Repository and OBS projects list]]&lt;br /&gt;
&lt;br /&gt;
'''What kinds of changes are accepted into 1.2.0-Update?'''&lt;br /&gt;
&lt;br /&gt;
Only bugs that are accepted as 1.2.0-Update blockers will be accepted into this project.  Anyone can propose a bug to be an update blocker bug for 1.2.0, and Release Engineering with feedback from the CCB makes decisions on accepting/rejecting their status as blockers.&lt;br /&gt;
&lt;br /&gt;
For more info on how this work, please go to this wiki:&lt;br /&gt;
&lt;br /&gt;
* [[Release_Engineering/Release_Timeline/Branching_phase#Which_changes_are_accepted_into_Branch|Which changes are accepted into a Branch]]&lt;br /&gt;
&lt;br /&gt;
''' What kinds of changes are accepted for the 1.2.1 release?'''&lt;br /&gt;
&lt;br /&gt;
Only bugs that are accepted as 1.2 blockers will be accepted into this project.  Anyone can propose a bug to be a blocker bug for 1.2, and Release Engineering with feedback from the CCB makes decisions on accepting/rejecting their status as blockers.&lt;br /&gt;
&lt;br /&gt;
For more info on how this work, please go to this wiki:&lt;br /&gt;
&lt;br /&gt;
* [[Release_Engineering/Release_Timeline/Branching_phase#Which_changes_are_accepted_into_Branch|Which changes are accepted into a Branch]]&lt;br /&gt;
&lt;br /&gt;
== MeeGo 1.2.0/1.2.1 Bug Track Process ==&lt;br /&gt;
&lt;br /&gt;
For MeeGo 1.2.0/1.2.1 bug track process, please refer to [http://wiki.meego.com/Quality/How_To_Report_Bugs#1.2.0.2F1.2.1_Bug_Tracking_Process 1.2.0/1.2.1 bug track process]&lt;br /&gt;
&lt;br /&gt;
== MeeGo 1.2 Release Plan by Date ==&lt;br /&gt;
&lt;br /&gt;
{| cellpadding=&amp;quot;5&amp;quot; cellspacing=&amp;quot;0&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
! Iteration !! Iteration&amp;lt;br/&amp;gt;Start -- End&amp;lt;br/&amp;gt;Dates !! MeeGo Release Focus !! Status&amp;lt;br/&amp;gt;URL !! Features&amp;lt;br/&amp;gt;Bugfixes&amp;lt;br/&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#ff9900&amp;quot; | 1.1.80.0&lt;br /&gt;
| 2010-09-30 -- 2010-10-06&lt;br /&gt;
| MM1: Trunk opened for 1.2 development on 2010-09-30.&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.0.20101005.1/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.80.0|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#ff9900&amp;quot; | 1.1.80.1&lt;br /&gt;
| 2010-10-07 -- 2010-10-13&lt;br /&gt;
| &lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.1.20101012.1/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.80.1|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#ff9900&amp;quot; | 1.1.80.2&lt;br /&gt;
| 2010-10-14 -- 2010-10-20&lt;br /&gt;
| &lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.2.20101019.1/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.80.2|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#ff9900&amp;quot; | 1.1.80.3&lt;br /&gt;
| 2010-10-21 -- 2010-10-27&lt;br /&gt;
| &lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.3.20101026.1/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.80.3|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#ff9900&amp;quot; | 1.1.80.4&lt;br /&gt;
| 2010-10-28 -- 2010-11-03&lt;br /&gt;
| &lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.4.20101102.1/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.80.4|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#ff9900&amp;quot; | 1.1.80.5&lt;br /&gt;
| 2010-11-04 -- 2010-11-10&lt;br /&gt;
| &lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.5.20101109.1/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.80.5|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#ff9900&amp;quot; | 1.1.80.6&lt;br /&gt;
| 2010-11-11 -- 2010-11-17&lt;br /&gt;
| &lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.6.20101116.1/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.80.6|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#ff9900&amp;quot; | 1.1.80.7&lt;br /&gt;
| 2010-11-18 -- 2010-11-24&lt;br /&gt;
| &lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.7.20101123.1/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.80.7|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#ffff00&amp;quot; | 1.1.80.8&lt;br /&gt;
| 2010-11-25 -- 2010-12-01&lt;br /&gt;
| MM2: Most intrusive changes delivered. Normal feature development continues after 2010-12-01. i18n code scans begin.&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.8.20101130.1/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.80.8|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#ffff00&amp;quot; | 1.1.80.9&lt;br /&gt;
| 2010-12-02 -- 2010-12-08&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.9.20101207.1/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.80.9|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#ffff00&amp;quot; | 1.1.80.10&lt;br /&gt;
| 2010-12-09 -- 2010-12-15&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.10.20101214.1/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.80.10|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#ffff00&amp;quot; | 1.1.80.11&lt;br /&gt;
| 2010-12-16 -- 2010-12-22&lt;br /&gt;
| MM2.5: checkpoint for features delivery&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.11.20101221.1/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.80.11|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#ffff00&amp;quot; | 1.1.80.12&lt;br /&gt;
| 2010-12-23 -- 2010-12-29&lt;br /&gt;
| Due to holidays in most of the countries, release has been skipped&lt;br /&gt;
|Skipped&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.80.12|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#ffff00&amp;quot; | 1.1.80.13&lt;br /&gt;
| 2010-12-30 -- 2011-01-05&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.13.20110105.1/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.80.13|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#ffff00&amp;quot; | 1.1.80.14&lt;br /&gt;
| 2011-01-06 -- 2011-01-12&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.14.20110111.8/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.80.14|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#ffff00&amp;quot; | 1.1.80.15&lt;br /&gt;
| 2011-01-13 -- 2011-01-19&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.15.20110118.5/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.80.15|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.1.90.0&lt;br /&gt;
| 2011-01-20 -- 2011-01-26&lt;br /&gt;
| MM3: All planned features released, Bugfixing for most of features starts after 2011-01-26, Possibility to integrate features that are late&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.80/1.1.90.0.20110125.3/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.90.0|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.1.90.1&lt;br /&gt;
| 2011-01-27 -- 2011-02-02&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/1.1.90/1.1.90.1.20110201.1/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.90.1|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.1.90.2&lt;br /&gt;
| 2011-02-03 -- 2011-02-09&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/trunk/1.1.90.2.20110208.4/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.90.2|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.1.90.3&lt;br /&gt;
| 2011-02-10 -- 2011-02-16&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/trunk/1.1.90.3.20110215.10/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.90.3|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.1.90.4&lt;br /&gt;
| 2011-02-17 -- 2011-02-23&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/trunk/1.1.90.4.20110222.2/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.90.4|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.1.90.5&lt;br /&gt;
| 2011-02-24 -- 2011-03-02&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/trunk/1.1.90.5.20110301.7/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.90.5|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.1.90.6&lt;br /&gt;
| 2011-03-03 -- 2011-03-09&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/trunk/1.1.90.6.20110308.5/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.90.6|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.1.90.7&lt;br /&gt;
| 2011-03-10 -- 2011-03-16&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://archive.meego.com/MeeGo/builds/trunk/1.1.90.7.20110315.10/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.90.7|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.1.90.8&lt;br /&gt;
| 2011-03-17 -- 2011-03-23&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://repo.meego.com/MeeGo/builds/trunk/1.1.90.8.20110322.2/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.90.8|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#00ff00&amp;quot; | 1.1.99.0&lt;br /&gt;
| 2011-03-24 -- 2011-03-30&lt;br /&gt;
| &lt;br /&gt;
| |Released&amp;lt;br/&amp;gt;[http://repo.meego.com/MeeGo/builds/trunk/1.1.99.0.20110329.5/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.99.0|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#00ff00&amp;quot; | 1.1.99.1&lt;br /&gt;
| 2011-03-31 -- 2011-04-06&lt;br /&gt;
| &lt;br /&gt;
| |Released&amp;lt;br/&amp;gt;[http://repo.meego.com/MeeGo/builds/trunk/1.1.99.1.20110405.3/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.99.1|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#00ff00&amp;quot; | 1.1.99.2&lt;br /&gt;
| 2011-04-07 -- 2011-04-13&lt;br /&gt;
| &lt;br /&gt;
| |Released&amp;lt;br/&amp;gt;[http://repo.meego.com/MeeGo/builds/trunk/1.1.99.2.20110412.6/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.99.2|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#00ff00&amp;quot; | 1.1.99.3&lt;br /&gt;
| 2011-04-14 -- 2011-04-20&lt;br /&gt;
| &lt;br /&gt;
| |Released&amp;lt;br/&amp;gt;[http://repo.meego.com/MeeGo/builds/trunk/1.1.99.3.20110419.9/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.99.3|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#00ff00&amp;quot; | 1.1.99.4&lt;br /&gt;
| 2011-04-21 -- 2011-04-27&lt;br /&gt;
| MeeGo 1.2.0 Initial pre-release image available (4-26)&lt;br /&gt;
| Released&amp;lt;br/&amp;gt;[http://repo.meego.com/MeeGo/builds/trunk/1.1.99.4.20110426.4/ Download]&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.99.4|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#00ff00&amp;quot; | 1.1.99.5&lt;br /&gt;
| 2011-04-28 -- 2011-05-04&lt;br /&gt;
| MeeGo 1.2.0 Branching from 1.2 (4-29)&lt;br /&gt;
|&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.99.5|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#00ff00&amp;quot; | 1.1.99.6&lt;br /&gt;
| 2011-05-05 -- 2011-05-11&lt;br /&gt;
| MeeGo 1.2.0 Final release candidate (5-6), MeeGo 1.2.0 Signed Gold image (5-10)&lt;br /&gt;
|&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.99.6|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#339966&amp;quot; | 1.1.99.7&lt;br /&gt;
| 2011-05-12 -- 2011-05-18 &lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.1.99.7|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#339966&amp;quot; | 1.2.0.0&lt;br /&gt;
| 2011-05-19 -- 2011-05-25 &lt;br /&gt;
| MeeGo 1.2.0 Release Day (5-19)&lt;br /&gt;
|&lt;br /&gt;
| [[Release_Engineering/Plans/1.2/1.2.0.0|Details]]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.2.0.90.0&lt;br /&gt;
| 2011-05-12 -- 2011-05-18 &lt;br /&gt;
| Only 'accepted' 1.2 and 1.2 Update blocker bugs will be accepted from here on until 1.2.1 release.&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;[http://repo.meego.com/MeeGo/builds/1.2.0.90/1.2.0.90.0.20110517.1/ download]&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.2.0.90.1&lt;br /&gt;
| 2011-05-19 -- 2011-05-25&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;&lt;br /&gt;
[http://repo.meego.com/MeeGo/builds/1.2.0.90/1.2.0.90.1.20110525.2/ Download]&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.2.0.90.2&lt;br /&gt;
| 2011-06-09 -- 2011-06-15&lt;br /&gt;
| String Freeze (June 15)&lt;br /&gt;
|Skipped&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.2.0.90.3&lt;br /&gt;
| 2011-06-02 -- 2011-06-08&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;&lt;br /&gt;
[http://repo.meego.com/MeeGo/builds/1.2.0.90/1.2.0.90.3.20110607.2/ Download]&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.2.0.90.4&lt;br /&gt;
| 2011-06-09 -- 2011-06-15&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;&lt;br /&gt;
[http://repo.meego.com/MeeGo/builds/1.2.0.90/1.2.0.90.4.20110614.1/ Download]&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.2.0.90.5&lt;br /&gt;
| 2011-06-16 -- 2011-06-22&lt;br /&gt;
|&lt;br /&gt;
|Released&amp;lt;br/&amp;gt;&lt;br /&gt;
[http://repo.meego.com/MeeGo/builds/1.2.0.90/1.2.0.90.5.20110621.5/ Download]&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.2.0.90.6&lt;br /&gt;
| 2011-06-23 -- 2011-06-29&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.2.0.90.7&lt;br /&gt;
| 2011-06-30 -- 2011-07-06&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.2.0.90.8&lt;br /&gt;
| 2011-07-07 -- 2011-07-13&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.2.0.90.9&lt;br /&gt;
| 2011-07-14 -- 2011-07-20&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.2.0.90.10&lt;br /&gt;
| 2011-07-21 -- 2011-07-27&lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.2.0.90.11&lt;br /&gt;
| 2011-08-04 -- 2011-08-10&lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.2.0.90.12&lt;br /&gt;
| 2011-08-11 -- 2011-08-17&lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.2.0.90.13&lt;br /&gt;
| 2011-08-18 -- 2011-08-24&lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#99cc00&amp;quot; | 1.2.0.90.14&lt;br /&gt;
| 2011-08-25 -- 2011-08-31&lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#00ff00&amp;quot; | 1.2.0.99.0&lt;br /&gt;
| 2011-09-01 -- 2011-09-07&lt;br /&gt;
| Start stabilization phase towards release.&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#00ff00&amp;quot; | 1.2.0.99.1&lt;br /&gt;
| 2011-09-08 -- 2011-09-14&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#00ff00&amp;quot; | 1.2.0.99.2&lt;br /&gt;
| 2011-09-15 -- 2011-09-21&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#00ff00&amp;quot; | 1.2.0.99.3&lt;br /&gt;
| 2011-09-22 -- 2011-09-28&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#339966&amp;quot; | 1.2.0.99.4&lt;br /&gt;
| 2011-09-29 -- 2011-10-05&lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background-color:#339966&amp;quot; | 1.2.1&lt;br /&gt;
| 2011-10-06 -- 2011-10-11&lt;br /&gt;
| MeeGo 1.2.1 Release Day (Tablet images &amp;amp; MeeGo repos)&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== MeeGo 1.2 Features Status ==&lt;br /&gt;
{{#bugzilla:&lt;br /&gt;
  |columns=id,status,to,severity,version,summary&lt;br /&gt;
  |product=MeeGo Core OS Features,MeeGo Handset Features,MeeGo Netbook Features,MeeGo IVI Features&lt;br /&gt;
  |version=1.2 &lt;br /&gt;
  |bar=status&lt;br /&gt;
  |group=product&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
[http://bugs.meego.com/report.cgi?x_axis_field=bug_status&amp;amp;y_axis_field=component&amp;amp;z_axis_field=product&amp;amp;query_format=report-table&amp;amp;classification=MeeGo+Features&amp;amp;product=MeeGo+Connected+TV+Features&amp;amp;product=MeeGo+Core+OS+Features&amp;amp;product=MeeGo+Handset+Features&amp;amp;product=MeeGo+IVI+Features&amp;amp;product=MeeGo+Netbook+Features&amp;amp;product=MeeGo+Tablet+Features&amp;amp;version=1.2&amp;amp;bug_severity=enhancement&amp;amp;format=table&amp;amp;action=wrap Detailed report in Featurezilla]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== MeeGo 1.2 Bugs Status ==&lt;br /&gt;
{{#bugzilla:&lt;br /&gt;
  |columns=id,status,to,severity,version,summary&lt;br /&gt;
  |product=MeeGo SDK,OS Base,OS Middleware,Handset User Experience,Netbook User Experience,Netbook IVI Experience&lt;br /&gt;
  |version=1.2 &lt;br /&gt;
  |bar=status&lt;br /&gt;
  |group=product&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
[http://bugs.meego.com/report.cgi?x_axis_field=bug_status&amp;amp;y_axis_field=component&amp;amp;z_axis_field=product&amp;amp;query_format=report-table&amp;amp;classification=MeeGo+Platform&amp;amp;product=Automotive+User+Experience&amp;amp;product=Handset+User+Experience&amp;amp;product=MeeGo+SDK&amp;amp;product=Netbook+User+Experience&amp;amp;product=OS+Base&amp;amp;product=OS+Middleware&amp;amp;version=1.2&amp;amp;format=table&amp;amp;action=wrap Detailed report in Bugzilla]&lt;br /&gt;
&lt;br /&gt;
[[Category:Release engineering]]&lt;br /&gt;
[[Category:Meego-1.2]]&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Build_Infrastructure/Packagers_Developers</id>
		<title>Build Infrastructure/Packagers Developers</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Build_Infrastructure/Packagers_Developers"/>
				<updated>2011-07-11T21:59:15Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* How to use the commandline client */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;These pages are in preparation - contributions welcome.&lt;br /&gt;
&lt;br /&gt;
 Note: See [[OBS|the OBS wiki page]] for explanation of the different OBS services MeeGo offers.&lt;br /&gt;
&lt;br /&gt;
This track will give you a brief introduction to the features and capabilities of the OBS instance hosted at build.meego.com. &lt;br /&gt;
Note: You need an account to access build.meego.com.  &lt;br /&gt;
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] .&lt;br /&gt;
&lt;br /&gt;
In this track, you'll learn how to use the web interface, the commandline client and create your first package.&lt;br /&gt;
The packaging guidelines and more advanced topics are also covered.&lt;br /&gt;
&lt;br /&gt;
== How to get started ==&lt;br /&gt;
&lt;br /&gt;
You need an account on build.meego.com. To request an account: &lt;br /&gt;
# Go to [http://bugs.meego.com MeeGo bugzilla]. &lt;br /&gt;
# Click New in the upper navigational bar to begin filing a bug. &lt;br /&gt;
# On the next page, click MeeGo Community Infrastructure. &lt;br /&gt;
# On the following page, click Build Service and file your bug.&lt;br /&gt;
&lt;br /&gt;
== How to use the web interface ==&lt;br /&gt;
A series of pages will make you familiar with webinterface basics. It's divided into several subpages:&lt;br /&gt;
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_1|Part 1 - Login and first steps]]&lt;br /&gt;
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_2|Part 2 - Creating a link and adding a repository]]&lt;br /&gt;
* [[Developing_in_a_MeeGo_Environment#Building_your_package:_Step_by_step|Part 3 - Your first own package]]&lt;br /&gt;
&lt;br /&gt;
== How to use the commandline client ==&lt;br /&gt;
* Part 1 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_1|initial setup]]&lt;br /&gt;
* Part 2 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|checkout and branch]]&lt;br /&gt;
* Part 3 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_3|commit &amp;amp; request]]&lt;br /&gt;
* Part 4 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_4|more commands: localcheckbuild]]&lt;br /&gt;
&lt;br /&gt;
== MeeGo Packaging guidelines and Howto ==&lt;br /&gt;
* [[Packaging|Packaging]]&lt;br /&gt;
* [[Packaging/Guidelines|Packaging Guidelines]]&lt;br /&gt;
* [[SDK/Docs/1.0/Packaging/Tutorial|Packaging Tutorial]]&lt;br /&gt;
&lt;br /&gt;
== [[Build_Infrastructure/QA|QA Processes around the OBS]] ==&lt;br /&gt;
See the [[Quality]] page.&lt;br /&gt;
&lt;br /&gt;
== Verifying Your Package Changes Locally and Online ==&lt;br /&gt;
* [[Build_Infrastructure/Packagers_Developers/Using_OBS_chroot_for_development|Using OBS chroot for development]]&lt;br /&gt;
&lt;br /&gt;
== Troubleshooting ==&lt;br /&gt;
&lt;br /&gt;
* '''I'm getting &amp;quot;error: Package already exists: %package debuginfo&amp;quot;''' &amp;amp;mdash; 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.&lt;br /&gt;
&lt;br /&gt;
== IRC / mailinglists / contact ==&lt;br /&gt;
&lt;br /&gt;
If you need help, you can join #meego on irc.freenode.net . See also [[Community communication|this page]] about all MeeGo IRC channels.&lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
[[Category:Build Infrastructure]]&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Distribution</id>
		<title>Distribution</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Distribution"/>
				<updated>2011-07-11T21:58:47Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* OBS command line */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This page describes basic information you needed if you want to contribute to MeeGo. Target audience is community member who wish to involve in MeeGo development.&lt;br /&gt;
&lt;br /&gt;
== Package Management and Development ==&lt;br /&gt;
=== Overview ===&lt;br /&gt;
[[File:Distribution-process-overview-with-obs.png|thumb|250px|right|The development process when using OBS]]&lt;br /&gt;
[[File:Distribution-process-without-obs.png|thumb|250px|right|The development process w/o using OBS]]&lt;br /&gt;
Like other Linux distros, MeeGo is a package-based system, and it is using [http://www.rpm.org/max-rpm/index.html RPM] package end. The RPM packages are managed in [http://wiki.meego.com/Zypper Zypper] repos. The MeeGo development is using [http://wiki.opensuse.org/Portal:Build_Service Open Build Service (OBS)] to manage and build packages. If you are a serious and frequent MeeGo contributor, you need an OBS account to commit your changes back to MeeGo. Casual contributors can work without using OBS, and submit your changes back into MeeGo through the [http://lists.meego.com/mailman/listinfo mailing list] or work with the package maintainers to submit changes.&lt;br /&gt;
&lt;br /&gt;
The overall processes of development with and without an OBS account are shown in the right figures. Detail description of the processes can be found below.&lt;br /&gt;
&lt;br /&gt;
=== Development with MeeGo OBS account === &lt;br /&gt;
* [[Build_Infrastructure/Packagers_Developers#How_to_get_started|Request a new OBS account]]&lt;br /&gt;
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_1|OBS WebUI: Login and first steps]]&lt;br /&gt;
* [[Build_Infrastructure/Packagers_Developers/WebUI_part_2|OBS WebUI: Link packages and adding a repository]]&lt;br /&gt;
* [[Build_Infrastructure/Packagers_Developers#How_to_use_the_commandline_client|How to use the command line client for daily operations]]&lt;br /&gt;
* [[Build_Infrastructure/Packagers_Developers/Using_OBS_chroot_for_development|Using OBS chroot for development]]&lt;br /&gt;
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]&lt;br /&gt;
* [[Build_Infrastructure/Packagers_Developers#Troubleshooting|Troubleshooting]]&lt;br /&gt;
&lt;br /&gt;
=== Development without MeeGo OBS account ===&lt;br /&gt;
* [[Local_Build_Without_OBS_Needed|Build and develop packages without OBS ]]&lt;br /&gt;
* [[Recompile_kernel | Example: Recompile kernel]]&lt;br /&gt;
* [[How to development with multiple packages with dependencies]]&lt;br /&gt;
* [[Distribution/Create_image_based_on_new_RPM|Create image based on new RPM]]&lt;br /&gt;
&lt;br /&gt;
=== Packaging ===&lt;br /&gt;
* [[Packaging/Guidelines|Packaging Guidelines]]&lt;br /&gt;
&lt;br /&gt;
=== Submission to MeeGo ===&lt;br /&gt;
* [[Release_Engineering/New_Package_Checklist|Checklist for new package submissions]]&lt;br /&gt;
* [[Release_Engineering/Submission_Checklist|Developer's checklist for code submissions]]&lt;br /&gt;
* [[Build_Infrastructure/Packagers_Developers#IRC_.2F_mailinglists_.2F_contact|irc / mailing lists / contact]]&lt;br /&gt;
&lt;br /&gt;
== Software Repo ==&lt;br /&gt;
* [[Create and update repos]]&lt;br /&gt;
* [[Distribution/Package_Management|Package Management]]&lt;br /&gt;
&lt;br /&gt;
== Developer Tools ==&lt;br /&gt;
=== Image Creation ===&lt;br /&gt;
* [[Image_Creation_For_Beginners|MIC2 for Beginners]]&lt;br /&gt;
* [[Image_Creation|MIC2]]&lt;br /&gt;
* [[Image Configurations - KickStart Files]]&lt;br /&gt;
&lt;br /&gt;
=== OBS command line ===&lt;br /&gt;
* Part 1 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_1|initial setup]]&lt;br /&gt;
* Part 2 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|checkout &amp;amp; branch]]&lt;br /&gt;
* Part 3 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_3|commit &amp;amp; request]]&lt;br /&gt;
* Part 4 - [[Build_Infrastructure/Packagers_Developers/CLI_Part_4|more commands: localcheckbuild]]&lt;br /&gt;
&lt;br /&gt;
=== Spec tool ===&lt;br /&gt;
* [[Spectacle|Spectacle]]&lt;br /&gt;
&lt;br /&gt;
== Distribution Infrastructure ==&lt;br /&gt;
* [[Build_Infrastructure|Build Infrastructure - OBS]]&lt;br /&gt;
* [[Release_Infrastructure/BOSS|Release Infrastructure - BOSS]]&lt;br /&gt;
&lt;br /&gt;
== Links ==&lt;br /&gt;
* [[Release_Engineering|Release Engineering]]&lt;br /&gt;
* [[Quality/Compliance|Compliance]]&lt;br /&gt;
* [[Quality|Quality]]&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Build_Infrastructure/Packagers_Developers/CLI_Part_3</id>
		<title>Build Infrastructure/Packagers Developers/CLI Part 3</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Build_Infrastructure/Packagers_Developers/CLI_Part_3"/>
				<updated>2011-07-11T21:57:30Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= How to use the MeeGo / OBS Command Line Tools, Part 3 =&lt;br /&gt;
&lt;br /&gt;
After some modification of the checked out files in local filesystem, you can use osc to commit the changes to OBS server. When the verification and testings are passed, you can continue to send merge request to the origin package.&lt;br /&gt;
osc can also provide command to do local building.&lt;br /&gt;
&lt;br /&gt;
== Commit ==&lt;br /&gt;
The following command can be used to add/remove files inside the package:&lt;br /&gt;
&lt;br /&gt;
 $ osc add &amp;lt;file&amp;gt;&lt;br /&gt;
 $ osc remove &amp;lt;file&amp;gt;&lt;br /&gt;
 $ osc addremove ($ osc ar)&lt;br /&gt;
&lt;br /&gt;
The following command can be used to commit all local changes to OBS server:&lt;br /&gt;
 &lt;br /&gt;
 $ osc ci [-m comments]&lt;br /&gt;
&lt;br /&gt;
If no comments string provided in the command line, osc will launch $EDITOR for it.&lt;br /&gt;
&lt;br /&gt;
== Send Merge Request ==&lt;br /&gt;
The following command can be used to send to merge request to origin package:&lt;br /&gt;
&lt;br /&gt;
 $ osc sr [O_Project] [O_Package] [-m comments]&lt;br /&gt;
&lt;br /&gt;
The requests will be reviewed by gate keepers, and they will be accepted or declined according the result. Whenever the request being accepted, the branched package will be deleted automatically.&lt;br /&gt;
&lt;br /&gt;
== Local Build ==&lt;br /&gt;
To mitigate the burden of OBS servers, user should do the first time building verification in local machine. The following command can be used to do so:&lt;br /&gt;
&lt;br /&gt;
 $ osc build &amp;lt;repo&amp;gt; &amp;lt;arch&amp;gt; &amp;lt;spec or dsc file&amp;gt;&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Build_Infrastructure/Packagers_Developers/CLI_Part_3</id>
		<title>Build Infrastructure/Packagers Developers/CLI Part 3</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Build_Infrastructure/Packagers_Developers/CLI_Part_3"/>
				<updated>2011-07-11T21:50:37Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: Created page with &amp;quot;= How to use the MeeGo / OBS Command Line Tools, Part 3 =  After some modification of the checked out files in local filesystem, you can use osc to commit the changes to OBS serv...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= How to use the MeeGo / OBS Command Line Tools, Part 3 =&lt;br /&gt;
&lt;br /&gt;
After some modification of the checked out files in local filesystem, you can use osc to commit the changes to OBS server. When the verification and testings are passed, you can continue to send merge request to the origin package.&lt;br /&gt;
osc can also provide command to do local building.&lt;br /&gt;
&lt;br /&gt;
== Commit ==&lt;br /&gt;
The following command can be used to add/remove files inside the package:&lt;br /&gt;
&lt;br /&gt;
 $ osc add &amp;lt;file&amp;gt;&lt;br /&gt;
 $ osc remove &amp;lt;file&amp;gt;&lt;br /&gt;
 $ osc addremove ($ osc ar)&lt;br /&gt;
&lt;br /&gt;
The following command can be used to commit all local changes to OBS server:&lt;br /&gt;
 &lt;br /&gt;
 $ osc ci [-m comments]&lt;br /&gt;
&lt;br /&gt;
If no comments string provided in the command line, osc will launch $EDITOR for it.&lt;br /&gt;
&lt;br /&gt;
== Send Merge Request ==&lt;br /&gt;
The following command can be used to send to merge request to origin package:&lt;br /&gt;
&lt;br /&gt;
 $ osc sr [O_Project] [O_Package] [-m comments]&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Build_Infrastructure/Packagers_Developers/CLI_Part_2</id>
		<title>Build Infrastructure/Packagers Developers/CLI Part 2</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Build_Infrastructure/Packagers_Developers/CLI_Part_2"/>
				<updated>2011-07-11T21:41:51Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* How to use the MeeGo / OBS Command Line Interface, Part 2 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= How to use the MeeGo / OBS Command Line Tools, Part 2 =&lt;br /&gt;
&lt;br /&gt;
You've used the set up the 'osc' tool in [[Build_Infrastructure/Packagers_Developers/CLI_Part_1|Part 1]] and now it's time to check out your project for local editing and build.&lt;br /&gt;
&lt;br /&gt;
== Find the project to checkout ==&lt;br /&gt;
&lt;br /&gt;
You can list projects you can check out using 'osc ls'. You will see your home project you created in the Web UI listed too:&lt;br /&gt;
&lt;br /&gt;
 $ osc ls&lt;br /&gt;
 Trunk&lt;br /&gt;
 Trunk:Testing&lt;br /&gt;
 devel:base&lt;br /&gt;
 ...&lt;br /&gt;
 home:&amp;lt;login&amp;gt;&lt;br /&gt;
 ...&lt;br /&gt;
&lt;br /&gt;
== Change to your OBS area ==&lt;br /&gt;
&lt;br /&gt;
Create a directory for doing work and change directory into it:&lt;br /&gt;
&lt;br /&gt;
 $ mkdir ~/obs&lt;br /&gt;
 $ cd ~/obs&lt;br /&gt;
&lt;br /&gt;
== Check out the desired project ==&lt;br /&gt;
&lt;br /&gt;
This is a lot like using Subversion or CVS as the model is 'checkout' and 'checkin' (abbreviated 'co' and 'ci', respectively):&lt;br /&gt;
&lt;br /&gt;
 $ osc co home:&amp;lt;login&amp;gt;&lt;br /&gt;
 A home:&amp;lt;login&amp;gt;&lt;br /&gt;
 A home:&amp;lt;login&amp;gt;:bash&lt;br /&gt;
 A home:&amp;lt;login&amp;gt;:bash/Makefile&lt;br /&gt;
 ...&lt;br /&gt;
&lt;br /&gt;
You will now find your checked out project ready for modification and rebuild under home:&amp;lt;login&amp;gt;/&amp;lt;packagename&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Branching a package to your home project ==&lt;br /&gt;
&lt;br /&gt;
If using MeeGo OBS:&lt;br /&gt;
&lt;br /&gt;
 $ osc branch Trunk:Testing &amp;lt;packagename&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Tips, use 'bco' subcommand alias will make osc checkout the branched package meanwhile:&lt;br /&gt;
&lt;br /&gt;
 $ osc bco Trunk:Testing &amp;lt;packagename&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary and next steps ==&lt;br /&gt;
&lt;br /&gt;
This guide gave an introduction on how to use the osc tool to checkout sources.&lt;br /&gt;
The next page will cover building your project. Click [[Build_Infrastructure/Packagers_Developers/CLI_Part_3|TBD]] to open the 3rd part.&lt;br /&gt;
&lt;br /&gt;
[[Category:Build Infrastructure]]&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Build_Infrastructure/Packagers_Developers/CLI_Part_1</id>
		<title>Build Infrastructure/Packagers Developers/CLI Part 1</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Build_Infrastructure/Packagers_Developers/CLI_Part_1"/>
				<updated>2011-07-11T21:35:45Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= How to use the MeeGo / OBS Command Line Tools =&lt;br /&gt;
&lt;br /&gt;
The command line tool `osc' can be used to access OBS services. The following content will show you how to install and configure it. Once you've successfully setuped the OBS command line tool, the next part will show you how to check out packages from the MeeGo project/package for local modification and building.&lt;br /&gt;
&lt;br /&gt;
== OSC Installation ==&lt;br /&gt;
&lt;br /&gt;
You will need to install some tools in order to access and build packages. This includes the command line client 'osc', and packages that it relies on.&lt;br /&gt;
&lt;br /&gt;
The easiest method is to use your distribution's package manager to pull the osc package and its requirements. Package repositories for many distributions are available [http://repo.meego.com/MeeGo/tools/repos/ here].&lt;br /&gt;
&lt;br /&gt;
 For example, with Fedora 12:&lt;br /&gt;
  # cd /etc/yum.repos.d&lt;br /&gt;
  # wget http://repo.meego.com/MeeGo/tools/repos/fedora/12/meego-tools.repo&lt;br /&gt;
  # yum install osc&lt;br /&gt;
&lt;br /&gt;
The upstream [http://en.opensuse.org/openSUSE:Build_Service_Tutorial OBS Tutorial] describes more generalities about using the tools.&lt;br /&gt;
&lt;br /&gt;
== Configuring OSC using $HOME/.oscrc ==&lt;br /&gt;
&lt;br /&gt;
OSC should be customized using the file $HOME/.oscrc for OBS service apiurl and the account settings.&lt;br /&gt;
When you run osc for the first time, the osc itself will create one for you with several questions. And&lt;br /&gt;
the following is a stripped sample oscrc:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[general]&lt;br /&gt;
apiurl = https://api.meego.com&lt;br /&gt;
&lt;br /&gt;
packagecachedir = /var/obs-tmp/osbuild-packagecache&lt;br /&gt;
build-root = /var/obs-tmp/build-root&lt;br /&gt;
&lt;br /&gt;
debug = 0&lt;br /&gt;
http_debug = 0&lt;br /&gt;
&lt;br /&gt;
extra-pkgs = gzip&lt;br /&gt;
&lt;br /&gt;
[https://api.meego.com]&lt;br /&gt;
user=user1&lt;br /&gt;
pass = passwd-in-plain-text&lt;br /&gt;
aliases=mg&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
In the above sample, &amp;quot;apiurl&amp;quot;, &amp;quot;user&amp;quot;, and &amp;quot;pass&amp;quot; keys should be replaced with the valid ones.&lt;br /&gt;
&lt;br /&gt;
=== Tips: su-wrapper setting ===&lt;br /&gt;
&lt;br /&gt;
  To make it easier to run needed things as root, configure for sudo&lt;br /&gt;
   In $HOME/.oscrc set:&lt;br /&gt;
    su-wrapper = sudo&lt;br /&gt;
   And then run 'visudo' and add the line:&lt;br /&gt;
    &amp;lt;yourlogin&amp;gt; ALL=NOPASSWD: /usr/bin/build&lt;br /&gt;
&lt;br /&gt;
=== Tips: build-boot setting ===&lt;br /&gt;
  If you tend to build for several different architectures/projects, it can be helpful to keep each build-root seperate, in $HOME/.oscrc, set:&lt;br /&gt;
   build-root = /var/tmp/build-root/%(project)s-%(arch)s-%(package)s&lt;br /&gt;
&lt;br /&gt;
=== Tips: Multiple OBS configration ===&lt;br /&gt;
&lt;br /&gt;
To use a different source of packages and build server access, you can easily create a wrapper script to do this for you:&lt;br /&gt;
&lt;br /&gt;
  $ cat &amp;gt; ~/bin/losc&lt;br /&gt;
  #!/bin/bash&lt;br /&gt;
  exec osc -Ahttps://api.meego.com &amp;quot;$@&amp;quot;&lt;br /&gt;
  $ chmod +x ~/bin/losc &lt;br /&gt;
&lt;br /&gt;
When you're using pub meego osc you should use:&lt;br /&gt;
  exec osc -Ahttps://api'''.pub'''.meego.com &amp;quot;$@&amp;quot;&lt;br /&gt;
instead of&lt;br /&gt;
  exec osc -Ahttps://api.meego.com &amp;quot;$@&amp;quot;&lt;br /&gt;
&lt;br /&gt;
== Summary and next steps ==&lt;br /&gt;
&lt;br /&gt;
This guide gave an introduction on how to set up and initialize the 'osc' tool.&lt;br /&gt;
Next you will check out your project from the server and build it. Click [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|here]] to open the 2nd part.&lt;br /&gt;
&lt;br /&gt;
[[Category:Build Infrastructure]]&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Build_Infrastructure/Packagers_Developers/CLI_Part_1</id>
		<title>Build Infrastructure/Packagers Developers/CLI Part 1</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Build_Infrastructure/Packagers_Developers/CLI_Part_1"/>
				<updated>2011-07-11T21:12:21Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* OSC Tool Installation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= How to use the MeeGo / OBS Command Line Interface =&lt;br /&gt;
&lt;br /&gt;
Once you've successfully used the the MeeGo / OBS web interface, we'll show you how you can check out packages from the MeeGo project/package for local modification and building.&lt;br /&gt;
&lt;br /&gt;
== OSC Tool Installation ==&lt;br /&gt;
&lt;br /&gt;
You will need to install some tools in order to access and build packages. This includes the command line client 'osc', and packages that it relies on.&lt;br /&gt;
&lt;br /&gt;
The easiest method is to use your distribution's package manager to pull the osc package and its requirements. Package repositories for many distributions are available [http://repo.meego.com/MeeGo/tools/repos/ here].&lt;br /&gt;
&lt;br /&gt;
 For example, with Fedora 12:&lt;br /&gt;
  # cd /etc/yum.repos.d&lt;br /&gt;
  # wget http://repo.meego.com/MeeGo/tools/repos/fedora/12/meego-tools.repo&lt;br /&gt;
  # yum install osc&lt;br /&gt;
&lt;br /&gt;
The upstream [http://en.opensuse.org/openSUSE:Build_Service_Tutorial OBS Tutorial] describes more generalities about using the tools.&lt;br /&gt;
&lt;br /&gt;
== Running OSC the first time ==&lt;br /&gt;
&lt;br /&gt;
Prepare to run OSC.&lt;br /&gt;
&lt;br /&gt;
 Tip: To use a different source of packages and build server access,&lt;br /&gt;
 you can easily create a wrapper script to do this for you:&lt;br /&gt;
  $ cat &amp;gt; ~/bin/losc&lt;br /&gt;
  #!/bin/bash&lt;br /&gt;
  exec osc -Ahttps://api.meego.com &amp;quot;$@&amp;quot;&lt;br /&gt;
  $ chmod +x ~/bin/losc &lt;br /&gt;
&lt;br /&gt;
When you're using pub meego osc you should use:&lt;br /&gt;
  exec osc -Ahttps://api'''.pub'''.meego.com &amp;quot;$@&amp;quot;&lt;br /&gt;
instead of&lt;br /&gt;
  exec osc -Ahttps://api.meego.com &amp;quot;$@&amp;quot;&lt;br /&gt;
&lt;br /&gt;
The first time, OSC will ask you some questions:&lt;br /&gt;
&lt;br /&gt;
 $ losc ls&lt;br /&gt;
  &lt;br /&gt;
 Your user account / password are not configured yet.&lt;br /&gt;
 You will be asked for them below, and they will be stored in&lt;br /&gt;
 /home/james/.oscrc for future use.&lt;br /&gt;
 &lt;br /&gt;
 Creating osc configuration file /home/james/.oscrc ...&lt;br /&gt;
 Username: &amp;lt;login&amp;gt;&lt;br /&gt;
 Password: &amp;lt;password&amp;gt;&lt;br /&gt;
 done&lt;br /&gt;
 *** certificate verify failed at depth 0&lt;br /&gt;
 Subject:  /O=build.linux.com/OU=Domain Control Validated/CN=build.linux.com&lt;br /&gt;
 Issuer:   /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287&lt;br /&gt;
 Valid:  May 14 21:46:46 2010 GMT - Apr 26 21:10:19 2012 GMT&lt;br /&gt;
 Fingerprint(MD5):   C13D91AB12008D2F9FD901A8FADDFC75&lt;br /&gt;
 Fingerprint(SHA1):  144018EC455C20F395F18879DFD75E5B500B84F0&lt;br /&gt;
 Reason: unable to get local issuer certificate&lt;br /&gt;
 Reason: certificate not trusted&lt;br /&gt;
 Reason: unable to verify the first certificate&lt;br /&gt;
 &lt;br /&gt;
 The server certificate failed verification&lt;br /&gt;
 &lt;br /&gt;
 Would you like to&lt;br /&gt;
 0 - quit (default)&lt;br /&gt;
 1 - continue anyways&lt;br /&gt;
 2 - trust the server certificate permanently&lt;br /&gt;
 9 - review the server certificate&lt;br /&gt;
 &lt;br /&gt;
 Enter choice [0129]: 2&lt;br /&gt;
&lt;br /&gt;
At this point the configuration is complete and osc completes the 'ls' command, listing available build targets. You should see your home project listed, ex: home:&amp;lt;login&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Tip: Configuring OSC using $HOME/.oscrc ==&lt;br /&gt;
&lt;br /&gt;
OSC may be customized using the file $HOME/.oscrc. Some hints:&lt;br /&gt;
&lt;br /&gt;
To make it easier to run needed things as root, configure for sudo&lt;br /&gt;
&lt;br /&gt;
 In $HOME/.oscrc set:&lt;br /&gt;
  su-wrapper = sudo&lt;br /&gt;
 And then run 'visudo' and add the line:&lt;br /&gt;
  &amp;lt;yourlogin&amp;gt; ALL=NOPASSWD: /usr/bin/build&lt;br /&gt;
&lt;br /&gt;
If you tend to build for several different architectures/projects, it can be helpful to keep each build-root seperate, in $HOME/.oscrc, set:&lt;br /&gt;
&lt;br /&gt;
 build-root = /var/tmp/build-root/%(project)s-%(arch)s-%(package)s&lt;br /&gt;
&lt;br /&gt;
== Summary and next steps ==&lt;br /&gt;
&lt;br /&gt;
This guide gave an introduction on how to set up and initialize the 'osc' tool.&lt;br /&gt;
Next you will check out your project from the server and build it. Click [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|here]] to open the 2nd part.&lt;br /&gt;
&lt;br /&gt;
[[Category:Build Infrastructure]]&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Build_Infrastructure/Packagers_Developers/CLI_Part_1</id>
		<title>Build Infrastructure/Packagers Developers/CLI Part 1</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Build_Infrastructure/Packagers_Developers/CLI_Part_1"/>
				<updated>2011-07-11T21:09:44Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* How to use the MeeGo / OBS Command Line Interface */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= How to use the MeeGo / OBS Command Line Interface =&lt;br /&gt;
&lt;br /&gt;
Once you've successfully used the the MeeGo / OBS web interface, we'll show you how you can check out packages from the MeeGo project/package for local modification and building.&lt;br /&gt;
&lt;br /&gt;
== OSC Tool Installation ==&lt;br /&gt;
&lt;br /&gt;
You will need to install some tools in order to access and build packages. This includes the command line client 'osc', and packages that it relies on.&lt;br /&gt;
&lt;br /&gt;
The easiest method is to use your distribution's package manager to pull the osc package and its requirements. Package repositories for many distributions are available [http://download.opensuse.org/repositories/openSUSE:/Tools/ here].&lt;br /&gt;
&lt;br /&gt;
 For example, with Fedora 12:&lt;br /&gt;
  # cd /etc/yum.repos.d&lt;br /&gt;
  # wget http://download.opensuse.org/repositories/openSUSE:/Tools/Fedora_12/openSUSE:Tools.repo&lt;br /&gt;
  # wget http://download.opensuse.org/repositories/openSUSE:/Tools:/MeeGo/Fedora_12/openSUSE:Tools:MeeGo.repo&lt;br /&gt;
  # yum install osc&lt;br /&gt;
&lt;br /&gt;
The upstream [http://en.opensuse.org/openSUSE:Build_Service_Tutorial OBS Tutorial] describes more generalities about using the tools.&lt;br /&gt;
&lt;br /&gt;
== Running OSC the first time ==&lt;br /&gt;
&lt;br /&gt;
Prepare to run OSC.&lt;br /&gt;
&lt;br /&gt;
 Tip: To use a different source of packages and build server access,&lt;br /&gt;
 you can easily create a wrapper script to do this for you:&lt;br /&gt;
  $ cat &amp;gt; ~/bin/losc&lt;br /&gt;
  #!/bin/bash&lt;br /&gt;
  exec osc -Ahttps://api.meego.com &amp;quot;$@&amp;quot;&lt;br /&gt;
  $ chmod +x ~/bin/losc &lt;br /&gt;
&lt;br /&gt;
When you're using pub meego osc you should use:&lt;br /&gt;
  exec osc -Ahttps://api'''.pub'''.meego.com &amp;quot;$@&amp;quot;&lt;br /&gt;
instead of&lt;br /&gt;
  exec osc -Ahttps://api.meego.com &amp;quot;$@&amp;quot;&lt;br /&gt;
&lt;br /&gt;
The first time, OSC will ask you some questions:&lt;br /&gt;
&lt;br /&gt;
 $ losc ls&lt;br /&gt;
  &lt;br /&gt;
 Your user account / password are not configured yet.&lt;br /&gt;
 You will be asked for them below, and they will be stored in&lt;br /&gt;
 /home/james/.oscrc for future use.&lt;br /&gt;
 &lt;br /&gt;
 Creating osc configuration file /home/james/.oscrc ...&lt;br /&gt;
 Username: &amp;lt;login&amp;gt;&lt;br /&gt;
 Password: &amp;lt;password&amp;gt;&lt;br /&gt;
 done&lt;br /&gt;
 *** certificate verify failed at depth 0&lt;br /&gt;
 Subject:  /O=build.linux.com/OU=Domain Control Validated/CN=build.linux.com&lt;br /&gt;
 Issuer:   /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287&lt;br /&gt;
 Valid:  May 14 21:46:46 2010 GMT - Apr 26 21:10:19 2012 GMT&lt;br /&gt;
 Fingerprint(MD5):   C13D91AB12008D2F9FD901A8FADDFC75&lt;br /&gt;
 Fingerprint(SHA1):  144018EC455C20F395F18879DFD75E5B500B84F0&lt;br /&gt;
 Reason: unable to get local issuer certificate&lt;br /&gt;
 Reason: certificate not trusted&lt;br /&gt;
 Reason: unable to verify the first certificate&lt;br /&gt;
 &lt;br /&gt;
 The server certificate failed verification&lt;br /&gt;
 &lt;br /&gt;
 Would you like to&lt;br /&gt;
 0 - quit (default)&lt;br /&gt;
 1 - continue anyways&lt;br /&gt;
 2 - trust the server certificate permanently&lt;br /&gt;
 9 - review the server certificate&lt;br /&gt;
 &lt;br /&gt;
 Enter choice [0129]: 2&lt;br /&gt;
&lt;br /&gt;
At this point the configuration is complete and osc completes the 'ls' command, listing available build targets. You should see your home project listed, ex: home:&amp;lt;login&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Tip: Configuring OSC using $HOME/.oscrc ==&lt;br /&gt;
&lt;br /&gt;
OSC may be customized using the file $HOME/.oscrc. Some hints:&lt;br /&gt;
&lt;br /&gt;
To make it easier to run needed things as root, configure for sudo&lt;br /&gt;
&lt;br /&gt;
 In $HOME/.oscrc set:&lt;br /&gt;
  su-wrapper = sudo&lt;br /&gt;
 And then run 'visudo' and add the line:&lt;br /&gt;
  &amp;lt;yourlogin&amp;gt; ALL=NOPASSWD: /usr/bin/build&lt;br /&gt;
&lt;br /&gt;
If you tend to build for several different architectures/projects, it can be helpful to keep each build-root seperate, in $HOME/.oscrc, set:&lt;br /&gt;
&lt;br /&gt;
 build-root = /var/tmp/build-root/%(project)s-%(arch)s-%(package)s&lt;br /&gt;
&lt;br /&gt;
== Summary and next steps ==&lt;br /&gt;
&lt;br /&gt;
This guide gave an introduction on how to set up and initialize the 'osc' tool.&lt;br /&gt;
Next you will check out your project from the server and build it. Click [[Build_Infrastructure/Packagers_Developers/CLI_Part_2|here]] to open the 2nd part.&lt;br /&gt;
&lt;br /&gt;
[[Category:Build Infrastructure]]&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Image_Configurations_-_KickStart_Files</id>
		<title>Image Configurations - KickStart Files</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Image_Configurations_-_KickStart_Files"/>
				<updated>2011-07-07T09:06:26Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;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.&lt;br /&gt;
&lt;br /&gt;
For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.&lt;br /&gt;
&lt;br /&gt;
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&lt;br /&gt;
&lt;br /&gt;
== Official MeeGo .ks files ==&lt;br /&gt;
The official MeeGo .ks files are here:&lt;br /&gt;
&lt;br /&gt;
Formal release: http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/&lt;br /&gt;
&lt;br /&gt;
Weekly build: http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.&lt;br /&gt;
&lt;br /&gt;
== Modify your .ks ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options&lt;br /&gt;
&lt;br /&gt;
=== Change Partition, Setup and Bootloader options ===&lt;br /&gt;
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.&lt;br /&gt;
''Example''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
lang en_US.UTF-8&lt;br /&gt;
keyboard us&lt;br /&gt;
timezone --utc America/New_York&lt;br /&gt;
auth --useshadow --enablemd5&lt;br /&gt;
part / --size 1500 --ondisk sda --fstype=ext3&lt;br /&gt;
rootpw meego&lt;br /&gt;
xconfig --startxonboot&lt;br /&gt;
bootloader --timeout=0 --append=&amp;quot;quiet&amp;quot;&lt;br /&gt;
desktop --autologinuser=meego  --defaultdesktop=xfce&lt;br /&gt;
user --name meego  --groups audio,video --password meego&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Specify Repos ===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
''Example''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# This is a comment&lt;br /&gt;
&lt;br /&gt;
# My first repo&lt;br /&gt;
repo   --name=trunk  --baseurl=http://mytrunk.myrepo.com&lt;br /&gt;
&lt;br /&gt;
# My second repo&lt;br /&gt;
#repo   --name=&amp;lt;repo-name-2&amp;gt;  --baseurl=&amp;lt; url | local-repo-dir &amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''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.&lt;br /&gt;
&lt;br /&gt;
To create a repo you can point to on your local developer machine, you can run the following command:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
createrepo -d &amp;lt;local-dir&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.&lt;br /&gt;
&lt;br /&gt;
=== Add Packages Groups and Packages ===&lt;br /&gt;
* Groups&lt;br /&gt;
This specifies exactly what packages will be included in your image. Package groups can be specified with a &amp;quot;@&amp;quot; preceding it, as you can see from the example below:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
%packages&lt;br /&gt;
# Example adding pkg groups&lt;br /&gt;
@Core&lt;br /&gt;
@X for Netbooks&lt;br /&gt;
@Base&lt;br /&gt;
@Development Tools&lt;br /&gt;
@&amp;lt;my-PkgGroup1&amp;gt;&lt;br /&gt;
@&amp;lt;my-PkgGroup2&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Package groups are defined in the 'patterns.xml' file, it defines the group names, and what packages are included in each package group, for example: http://repo.meego.com/MeeGo/releases/1.2.0/repos/oss/ia32/packages/repodata/patterns.xml&lt;br /&gt;
&lt;br /&gt;
The MeeGo package groups are standard and common for MeeGo image creation. You can define your own package groups in your own non-meego repos in local, if you are using those.&lt;br /&gt;
&lt;br /&gt;
Please see here for more info in repositories about MeeGo package groups defination: https://meego.gitorious.org/meego-os-base/package-groups/&lt;br /&gt;
&lt;br /&gt;
* Packages&lt;br /&gt;
You can also add individual packages to the image, for example.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
%packages&lt;br /&gt;
# Example adding individual pkgs&lt;br /&gt;
kernel-netbook&lt;br /&gt;
xorg-x11-server-Xorg-setuid&lt;br /&gt;
carrick&lt;br /&gt;
xorg-x11-drv-evtouch&lt;br /&gt;
&amp;lt;my-pkg-1&amp;gt;&lt;br /&gt;
&amp;lt;my-pkg-2&amp;gt;&lt;br /&gt;
%end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== How MIC2 picks a package when different versions are available ===&lt;br /&gt;
A common question is that, a packageA may has more than one copy with different versions residing in a repo(s) that your .ks is pointing to. How will the MIC2 know which one to pick?&lt;br /&gt;
&lt;br /&gt;
* select the package with highest version number by default&lt;br /&gt;
''Example:''&lt;br /&gt;
&lt;br /&gt;
In the repo(s) these are different versions of PackageA:&amp;lt;br&amp;gt;&lt;br /&gt;
 PackageA-1.0&lt;br /&gt;
 PackageA-2.0&lt;br /&gt;
 PackageA-3.0&lt;br /&gt;
MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).&lt;br /&gt;
&lt;br /&gt;
* select the package through &amp;quot;Epoch&amp;quot; version&lt;br /&gt;
There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file, such as:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Name: &amp;lt;name&amp;gt;&lt;br /&gt;
Summary: &amp;lt;summary&amp;gt;&lt;br /&gt;
Epoch: 1&lt;br /&gt;
Version: &amp;lt;version&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
''Example:''&amp;lt;br&amp;gt;&lt;br /&gt;
 PackageA-1.0 (Epoch not set)&lt;br /&gt;
 PackageA-2.0 (Epoch = 1)&lt;br /&gt;
 PackageA-3.0 (Epoch not set)&lt;br /&gt;
&lt;br /&gt;
MIC2 will choose PackageA-2.0 in this case.  And it follow that:&lt;br /&gt;
&lt;br /&gt;
''Example:''&amp;lt;br&amp;gt;&lt;br /&gt;
 PackageA-1.0 (Epoch=100)&lt;br /&gt;
 PackageA-2.0 (Epoch = 1)&lt;br /&gt;
 PackageA-3.0 (Epoch not set)&lt;br /&gt;
&lt;br /&gt;
MIC2 will choose PackageA-1.0.&lt;br /&gt;
&lt;br /&gt;
Remember that MeeGo packages will not have 'Epoch' set, so if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.&lt;br /&gt;
&lt;br /&gt;
=== Remove Packages ===&lt;br /&gt;
&lt;br /&gt;
If you would like to make sure that a pkg should NOT be included, you can specify that with a '-' preceding the package name.&lt;br /&gt;
&lt;br /&gt;
''Example:''&lt;br /&gt;
packages 'carrick' and 'package-xyz' will _not_ be included in the image&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
%packages&lt;br /&gt;
# Example pkg groups&lt;br /&gt;
@Core&lt;br /&gt;
&lt;br /&gt;
# Example adding individual pkgs&lt;br /&gt;
kernel-netbook&lt;br /&gt;
&lt;br /&gt;
# Example removing individual pkgs&lt;br /&gt;
-carrick&lt;br /&gt;
-package-xyz&lt;br /&gt;
%end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Note:''' all packages that depend on the package you want to remove should be removed also, otherwise MIC2 will ignore your request and keep that package in the image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it will include both of these pgks in the image.&lt;br /&gt;
&lt;br /&gt;
=== Post scripts ===&lt;br /&gt;
&lt;br /&gt;
You can also specify post-scripts to be run after the image is created.&lt;br /&gt;
&lt;br /&gt;
''Example:''&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
%post&lt;br /&gt;
# Example - saving some space&lt;br /&gt;
rm -f /boot/initrd*&lt;br /&gt;
rm -f /core*&lt;br /&gt;
&lt;br /&gt;
# Example - Install working xorg.conf&lt;br /&gt;
if [ -f /usr/share/my.conf ]; then&lt;br /&gt;
    cp /usr/share/my.conf /etc/X11/xorg.conf&lt;br /&gt;
fi&lt;br /&gt;
&lt;br /&gt;
# Example - Tell alsa the correct audio card to use for your platform&lt;br /&gt;
echo -e &amp;quot;options snd-hda-intel index=0\noptions snd-timbi2s index=1&amp;quot; &amp;gt; /etc/modp&lt;br /&gt;
robe.d/alsa.conf&lt;br /&gt;
%end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Generate .ks file from Kickstarter ==&lt;br /&gt;
You can also create .ks files by kickstarter from image-configurations.&lt;br /&gt;
&lt;br /&gt;
=== Kickstarter ===&lt;br /&gt;
Kickstarter is a tool for create kickstart files to build meego images.&lt;br /&gt;
&lt;br /&gt;
You can download it here: http://repo.meego.com/MeeGo/tools/repos/meego/trunk/noarch/&lt;br /&gt;
&lt;br /&gt;
This tool is also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=kickstarter&amp;amp;project=Trunk&lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
  kickstarter  --configs configurations.yaml --repos repos.yaml &lt;br /&gt;
&lt;br /&gt;
Configuration file:&lt;br /&gt;
The &amp;quot;configuration.yaml&amp;quot; file here is an example only, for meego kickstart files, please get from the image-configurations package.&lt;br /&gt;
&lt;br /&gt;
This file has the definition of configurations. The Configurations inherit from platforms first then from the DEFAULT section. The image configurations override the all other settings (in DEFAULT and platform sections).&lt;br /&gt;
&lt;br /&gt;
Repo file:&lt;br /&gt;
This file contains a list of repositories to be used in the kickstart files.&lt;br /&gt;
&lt;br /&gt;
=== image-configuration ===&lt;br /&gt;
You can get image-configurations noarch package here: http://download.meego.com/live/Trunk/standard/noarch/&lt;br /&gt;
&lt;br /&gt;
The package of image-configurations also maintained by MeeGo OBS, in Trunk project: http://build.meego.com/package/show?package=image-configurations&amp;amp;project=Trunk &lt;br /&gt;
The organization of image-configurations:&lt;br /&gt;
&lt;br /&gt;
  configuration.yaml -- default and platform generic configs, also point to external platform path, it's the entrance for kickstart.&lt;br /&gt;
  repos.yaml         -- a list of repositories to be used in the kickstart files&lt;br /&gt;
  core               -- path for image-configs under 'core' platform &lt;br /&gt;
  compliance         -- path for image-configs under 'compliance' platform &lt;br /&gt;
  ivi                -- path for image-configs under 'ivi' platform &lt;br /&gt;
  handset            -- path for image-configs under 'handset' platform &lt;br /&gt;
  netbook            -- path for image-configs under 'netbook' platform &lt;br /&gt;
  tablet             -- path for image-configs under 'tablet' platform &lt;br /&gt;
  custom/part        -- store partition definition&lt;br /&gt;
  custom/scripts     -- store postscripts definition&lt;br /&gt;
&lt;br /&gt;
The followings are how does image-configurations manage those parts in .ks files.&lt;br /&gt;
&lt;br /&gt;
This configurations.yaml file has a generic definition of configurations. &lt;br /&gt;
The Configurations inherit from platforms first then from the DEFAULT section.&lt;br /&gt;
The image configurations override all other settings &lt;br /&gt;
(in DEFAULT and platform sections).&lt;br /&gt;
&lt;br /&gt;
Basically all common options should go to the DEFAULT section. If an options is&lt;br /&gt;
related to a specific platform, then that option should be added to the platform&lt;br /&gt;
section. Try to keep platforms clean and very generic, if needed, create a new&lt;br /&gt;
platform section and use it when many options for a new platform are common.&lt;br /&gt;
&lt;br /&gt;
'''''Detail for the keywords'''''&lt;br /&gt;
&lt;br /&gt;
&amp;quot;Name&amp;quot;: description of the configuration file&lt;br /&gt;
  Name: MeeGo Netbook/Nettop  &lt;br /&gt;
&lt;br /&gt;
&amp;quot;Schedule&amp;quot;: When should this image be generated:&lt;br /&gt;
  # *: always&lt;br /&gt;
  # 0: Monday&lt;br /&gt;
  # 1: Tuesday&lt;br /&gt;
  # ...&lt;br /&gt;
  # If no schedule keyword is present, then image will not be created&lt;br /&gt;
 &lt;br /&gt;
  Schedule: &amp;quot;*&amp;quot;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;Active&amp;quot;: if this image is active&lt;br /&gt;
  Active: True&lt;br /&gt;
&lt;br /&gt;
&amp;quot;Platform&amp;quot;: Inherit from platform&lt;br /&gt;
  Platform: NETBOOK&lt;br /&gt;
&lt;br /&gt;
&amp;quot;Part&amp;quot;: Partition specific configs&lt;br /&gt;
  Part: qemu&lt;br /&gt;
  &lt;br /&gt;
  # Part are stored in custom/part and referenced by part name&lt;br /&gt;
&lt;br /&gt;
&amp;quot;Kernel&amp;quot;: Based kernel&lt;br /&gt;
  Kernel: kernel-adaptation-mrst&lt;br /&gt;
&lt;br /&gt;
&amp;quot;Architecture&amp;quot;: Based architecture&lt;br /&gt;
  Architecture: ia32&lt;br /&gt;
&lt;br /&gt;
&amp;quot;Mic2Options&amp;quot;: MIC2 options to be used when creating this image&lt;br /&gt;
  Mic2Options: &amp;quot;-f livecd&amp;quot;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;Desktop&amp;quot;: Desktop type&lt;br /&gt;
  Desktop: None &lt;br /&gt;
&lt;br /&gt;
&amp;quot;Timezone&amp;quot;&lt;br /&gt;
  Timezone: America/New_York&lt;br /&gt;
&lt;br /&gt;
&amp;quot;FileName&amp;quot;: The name of the configuration file&lt;br /&gt;
  FileName: netbook-ia32&lt;br /&gt;
&lt;br /&gt;
&amp;quot;Groups&amp;quot;: package groups&lt;br /&gt;
  Groups:&lt;br /&gt;
     - MeeGo Netbook Desktop&lt;br /&gt;
     - MeeGo Core&lt;br /&gt;
     - Printing&lt;br /&gt;
     - Games&lt;br /&gt;
&lt;br /&gt;
&amp;quot;ExtraPackages&amp;quot;: Additional packages that are not part of any group&lt;br /&gt;
  ExtraPackages:&lt;br /&gt;
     - chromium&lt;br /&gt;
     - adobe-release&lt;br /&gt;
     - flash-plugin&lt;br /&gt;
&lt;br /&gt;
&amp;quot;Repos&amp;quot;: Repos to use in addition to default repos, those are define in the repos.yaml file&lt;br /&gt;
  Repos:&lt;br /&gt;
     - adobe&lt;br /&gt;
&lt;br /&gt;
&amp;quot;PostScripts&amp;quot;: Post-scripts to be run after the image is installed&lt;br /&gt;
  PostScripts:&lt;br /&gt;
     - meegotouch-n900&lt;br /&gt;
     - bootchart&lt;br /&gt;
     - fstab-n900&lt;br /&gt;
     - arch-armv7hl&lt;br /&gt;
  &lt;br /&gt;
  # post-scripts are stored in custom/scripts and referenced by post-scripts name&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Spectacle</id>
		<title>Spectacle</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Spectacle"/>
				<updated>2011-02-25T07:35:28Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Spectacle is the toolset for packaging maintenance of MeeGo, including the tool&lt;br /&gt;
to generate spec files from metadata file in YAML format, and tools to convert  &lt;br /&gt;
spec files or spec-builder's ini files to YAML format.                          &lt;br /&gt;
&lt;br /&gt;
For spectacle managed packages, all generic packaging information will be stored&lt;br /&gt;
in the YAML file, and it also allows maintaining customizations in the spec file&lt;br /&gt;
directly with special enclosure tags.                                           &lt;br /&gt;
&lt;br /&gt;
Three separated tools will be installed:&lt;br /&gt;
&lt;br /&gt;
* specify: the tool to generate or to update spec file, based on YAML&lt;br /&gt;
* ini2spectacle: the tool to convert spec-builder .ini to YAML and new spec file&lt;br /&gt;
* spec2spectacle: the tool to convert original spec to YAML and new spec file&lt;br /&gt;
&lt;br /&gt;
== Installation ==&lt;br /&gt;
=== Instruction ===&lt;br /&gt;
Several methods available for spectacle installation:&lt;br /&gt;
&lt;br /&gt;
* Install rpm/deb packages for several supported Linux distributions.&lt;br /&gt;
  From [http://repo.meego.com/tools/repos/ MeeGo Tools Repo], repo urls and install packages can be found for:&lt;br /&gt;
    * MeeGo&lt;br /&gt;
    * Fedora 10,11,12&lt;br /&gt;
    * openSUSE(s)    &lt;br /&gt;
    * xUbuntu 8.10/9.04/9.10/10.04&lt;br /&gt;
    * Debian 5.0            &lt;br /&gt;
&lt;br /&gt;
* Build from the latest source and install it by ``make install``&lt;br /&gt;
  The latest code in git tree can be accessed at:&lt;br /&gt;
  [git://gitorious.org/meego-developer-tools/spectacle.git]&lt;br /&gt;
&lt;br /&gt;
'''Note on Ubuntu installation'''&lt;br /&gt;
From [http://bugs.meego.com/show_bug.cgi?id=6734 this] Edit or create ''/etc/apt/sources.list.d/meego.list'' with sudo&lt;br /&gt;
Add&lt;br /&gt;
 deb http://repo.meego.com/MeeGo/tools/repos/ubuntu/9.10/ /&lt;br /&gt;
&lt;br /&gt;
run the following commands&lt;br /&gt;
 sudo apt-get update&lt;br /&gt;
&lt;br /&gt;
=== Requirements ===&lt;br /&gt;
* python 2.x, above 2.5&lt;br /&gt;
* PyYAML, the python module for YAML parsing&lt;br /&gt;
* cheetah, one popular templating system for python&amp;lt;br&amp;gt;&lt;br /&gt;
    In many linux distributions, the needed package might be &amp;quot;python-cheetah&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
* specify&lt;br /&gt;
    Usage: specify [options] [yaml-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output spec file&lt;br /&gt;
      -s, --skip-scm        Skip to check upstream SCM when specified in YAML&lt;br /&gt;
      -N, --not-download    Do not try to download newer source files&lt;br /&gt;
      -n, --non-interactive&lt;br /&gt;
                              Non interactive running, to use default answers&lt;br /&gt;
       --new=NEWYAML         Create a new yaml from template&lt;br /&gt;
       --newsub=NEWSUB       Append a new sub-package to current yaml&lt;br /&gt;
&lt;br /&gt;
* ini2spectacle&lt;br /&gt;
    Usage: ini2spectacle [options] [ini-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output yaml file&lt;br /&gt;
      -f, --include-files   To store files list in YAML file&lt;br /&gt;
&lt;br /&gt;
* spec2spectacle&lt;br /&gt;
    Usage: spec2spectacle [options] [spec-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output yaml file&lt;br /&gt;
      -r, --replace-macros  To replace self-defined macros in spec file&lt;br /&gt;
      --no-builder-parsing  Do NOT try to parse build/install scripts&lt;br /&gt;
      -f, --include-files   To store files list in YAML file&lt;br /&gt;
&lt;br /&gt;
== Syntax of spectacle YAML ==&lt;br /&gt;
The syntax of YAML can be refered here: &amp;lt;http://www.yaml.org/spec/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Two example spectacle YAML files are placed to examples/ directory in source&lt;br /&gt;
code:&lt;br /&gt;
&lt;br /&gt;
* xfce4-session.yaml, a real world sample with most of the elements&lt;br /&gt;
* general.yaml, a fake spectacle contains all the available elements with comments&lt;br /&gt;
&lt;br /&gt;
All available directives for spectacle are listed as the following:&lt;br /&gt;
&lt;br /&gt;
* Name: **string**&lt;br /&gt;
&lt;br /&gt;
* Summary: **string**&lt;br /&gt;
&lt;br /&gt;
* Version: **string**, version string&lt;br /&gt;
&lt;br /&gt;
* Release: **string**&lt;br /&gt;
&lt;br /&gt;
* Epoch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Group: **string**&lt;br /&gt;
&lt;br /&gt;
* License: **string**&lt;br /&gt;
&lt;br /&gt;
* URL: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* BuildArch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* ExclusiveArch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Prefix: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* LocaleName: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* LocaleOptions: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Description: **text**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Sources: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* SourcePrefix: **string**, *optional*, specify the prefix path in source package&lt;br /&gt;
&lt;br /&gt;
* ExtraSources: **list** of **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* SetupOptions: **string**, *optional*, the options string for %setup&lt;br /&gt;
&lt;br /&gt;
* Patches: **list** of **string**, all patches need to be in 'p1' level&lt;br /&gt;
&lt;br /&gt;
* Requires: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPre: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPreUn: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPost: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPostUn: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* PkgBR: **list** of **string**, packages required in building, or BuildRequires&lt;br /&gt;
&lt;br /&gt;
* PkgConfigBR: **list** of **string**, pkg-config requires in building&lt;br /&gt;
&lt;br /&gt;
* Provides: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Conflicts: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Obsoletes: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* BuildConflicts: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Configure: **string**, *optional*, valid values: **autogen**, **configure**, **reconfigure**, **none**&amp;lt;br&amp;gt;&lt;br /&gt;
** If not specified, the default value &amp;quot;configure&amp;quot; will be used&lt;br /&gt;
&lt;br /&gt;
* ConfigOptions: **list**, *optional*, extra options for ``Configure``&lt;br /&gt;
&lt;br /&gt;
* Builder: **string**, *optional*, valid values: **make**, **single-make**, **python**, **perl**, **qmake**, **none**&amp;lt;br&amp;gt;&lt;br /&gt;
** If not specified, the deault value &amp;quot;make&amp;quot; will be used. If do not want a automatic builder, please use &amp;quot;none&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* QMakeOptions: **list**, *optional*, extra options for **qmake** ``Builder``&lt;br /&gt;
&lt;br /&gt;
* Files: **list** of **string**, *optional*, content of ``%files`` for small packages&lt;br /&gt;
&lt;br /&gt;
* FilesInput: **string**, *optional*, extra input source for %files&lt;br /&gt;
&lt;br /&gt;
* NoFiles: **boolean**, *optional*, if to be set as True, means no %files section for this package and it cause no rpm generated&lt;br /&gt;
&lt;br /&gt;
* RunFdupes: **list** of **string**, paths under %{buildroot} to run ``%fdupes`` macro in %install&lt;br /&gt;
&lt;br /&gt;
* RpmLintIgnore: **list**, *optional*, list of skip items for ``rpmlint``&lt;br /&gt;
&lt;br /&gt;
* Check: **boolean**, whether need ``%check`` section in spec&lt;br /&gt;
&lt;br /&gt;
* SupportOtherDistros: **boolean**, whether need to check for other distros (besides MeeGo)&lt;br /&gt;
&lt;br /&gt;
* UseAsNeeded: **boolean**, whether export LD\_AS\_NEEDED=1 environ variable before building&lt;br /&gt;
&lt;br /&gt;
* NoAutoReq: **boolean**, whether add 'AutoReq: 0' to spec&lt;br /&gt;
&lt;br /&gt;
* NoAutoProv: **boolean**, whether add 'AutoProv: 0' to spec&lt;br /&gt;
&lt;br /&gt;
* NoSetup: **boolean**, whether to skip using ``%setup`` in ``%prep``&lt;br /&gt;
&lt;br /&gt;
* NoAutoLocale: **boolean**, whether to use ``%find_lang`` to search locale data when found 'intltool' in PkgBR&lt;br /&gt;
&lt;br /&gt;
* NoDesktop: **boolean**, whether to install the desktop files in package&lt;br /&gt;
&lt;br /&gt;
* UpdateDesktopDB: **boolean**, whether to run 'update-desktop-database' to flush cache when package (un)installation&lt;br /&gt;
&lt;br /&gt;
* NoIconCache: **boolean**, whether to run 'gtk-update-icon-cache' if icon files found in package&lt;br /&gt;
&lt;br /&gt;
* AutoDepend: **boolean**, for subpackages only, whether to add Require to main package automatically&lt;br /&gt;
&lt;br /&gt;
* AsWholeName: **boolean**, for subpackages only, whether to use **Name** as the whole package name&lt;br /&gt;
&lt;br /&gt;
* AutoSubPackages: **list** of **string**, mainly for '-devel'&lt;br /&gt;
&lt;br /&gt;
* SubPackages: **list** of **dict**, the **dict** item is the lower level directives for sub packages:&lt;br /&gt;
&lt;br /&gt;
    * Name&lt;br /&gt;
    * Summary&lt;br /&gt;
    * Description, *optional*&lt;br /&gt;
    * Group, *optional*&lt;br /&gt;
    * License, *optional*&lt;br /&gt;
    * Requires, *optional*&lt;br /&gt;
    * etc.&lt;br /&gt;
&lt;br /&gt;
'''CAUTION''': The following cases of value string have special meaning in YAML syntax:&lt;br /&gt;
* string with leading **``%``** charactor&lt;br /&gt;
* string with leading **``*``** charactor&lt;br /&gt;
* string contains **``:``** charactor and one or more spaces/tabs after **``:``**&lt;br /&gt;
* string end with **``:``** charactor&lt;br /&gt;
&lt;br /&gt;
Then these string values need to be quoted by ``'``(single-quote) or ``&amp;quot;``&lt;br /&gt;
(double-quote), and the choice of quote char should not conflict with the value&lt;br /&gt;
string self.&lt;br /&gt;
&lt;br /&gt;
== Mandatory and valid keywords for all packages ==&lt;br /&gt;
=== Mandatory keywords ===&lt;br /&gt;
The following keywords are mandatory for main package:&lt;br /&gt;
&lt;br /&gt;
* Name&lt;br /&gt;
* Summary&lt;br /&gt;
* Description&lt;br /&gt;
* Version&lt;br /&gt;
* Group&lt;br /&gt;
* License&lt;br /&gt;
&lt;br /&gt;
The following keywords are mandatory for sub-package:&lt;br /&gt;
&lt;br /&gt;
* Name&lt;br /&gt;
* Summary&lt;br /&gt;
* Description&lt;br /&gt;
* Group&lt;br /&gt;
&lt;br /&gt;
=== Valid keywords for sub-packages ===&lt;br /&gt;
For sub-packages, only a subset of keywords can be specified:&lt;br /&gt;
&lt;br /&gt;
* Name&lt;br /&gt;
* Summary&lt;br /&gt;
* Description&lt;br /&gt;
* Group&lt;br /&gt;
* License&lt;br /&gt;
* Version&lt;br /&gt;
* Release&lt;br /&gt;
* Epoch&lt;br /&gt;
* URL&lt;br /&gt;
* BuildArch&lt;br /&gt;
* Files&lt;br /&gt;
* Prefix&lt;br /&gt;
* Requires&lt;br /&gt;
* RequiresPre&lt;br /&gt;
* RequiresPreUn&lt;br /&gt;
* RequiresPost&lt;br /&gt;
* RequiresPostUn&lt;br /&gt;
* Provides&lt;br /&gt;
* Conflicts&lt;br /&gt;
* Obsoletes&lt;br /&gt;
* NoAutoReq&lt;br /&gt;
* NoAutoProv&lt;br /&gt;
* NoAutoReqProv&lt;br /&gt;
* NoIconCache&lt;br /&gt;
* FilesInput&lt;br /&gt;
&lt;br /&gt;
=== Keywords only for sub-packages ===&lt;br /&gt;
The following keywords are only valid for sub-packages:&lt;br /&gt;
&lt;br /&gt;
* AsWholeName&lt;br /&gt;
* AutoDepend&lt;br /&gt;
&lt;br /&gt;
== Namespace support for multi-architecture in several keywords ==&lt;br /&gt;
For the following spectacle YAML keywords:&lt;br /&gt;
&lt;br /&gt;
* Requires&lt;br /&gt;
* PkgBR&lt;br /&gt;
* PkgConfigBR&lt;br /&gt;
* Patches&lt;br /&gt;
* ConfigOptions&lt;br /&gt;
* QMakeOptions&lt;br /&gt;
&lt;br /&gt;
If one of the items need to be architecture specified, we can add arch prefix to&lt;br /&gt;
it. The supported prefix and the corresponding architectures as the followings:&lt;br /&gt;
&lt;br /&gt;
* ``ix86:`` -   x86 platform&lt;br /&gt;
* ``arm:``  -   arm platform&lt;br /&gt;
* ``armv5:``  -   armv5 platform, will expand to &amp;quot;armv5el armv5tel armv5tejl&amp;quot;&lt;br /&gt;
* ``armv7:``  -   armv7 platform, will expand to &amp;quot;armv7el armv7tel armv7l armv7hl armv7nhl&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Here's some samples:&lt;br /&gt;
&lt;br /&gt;
    Requires:&lt;br /&gt;
        - arm:pkg-need-in-arm-image&lt;br /&gt;
        - ix86:pkg-need-in-x86-image&lt;br /&gt;
        - normal-pkg&lt;br /&gt;
    ConfigOptions:&lt;br /&gt;
        - arm:--arm-specific-opt&lt;br /&gt;
        - ix86:--ix86-specific-opt&lt;br /&gt;
        - --common-opt&lt;br /&gt;
&lt;br /&gt;
== Customizations in spec ==&lt;br /&gt;
Generated spec files by specify will have many placeholders for customizations,&lt;br /&gt;
such as:&lt;br /&gt;
&lt;br /&gt;
    # &amp;gt;&amp;gt; build pre&lt;br /&gt;
    # &amp;lt;&amp;lt; build pre&lt;br /&gt;
&lt;br /&gt;
You can add any custom code between the markers, next time when you run&lt;br /&gt;
``specify``, the text between the markers will be kept as is, all other sections&lt;br /&gt;
relying on the meta data from the YAML file will be changed depending on the&lt;br /&gt;
values in the YAML file.&lt;br /&gt;
&lt;br /&gt;
The following placeholders in spec can be customized:&lt;br /&gt;
&lt;br /&gt;
* Private Macros, used in this package's spec&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; macros&lt;br /&gt;
        # &amp;lt;&amp;lt; macros&lt;br /&gt;
&lt;br /&gt;
* Extra setup scripts in the last of ``%prep``&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; setup&lt;br /&gt;
        # &amp;lt;&amp;lt; setup&lt;br /&gt;
&lt;br /&gt;
* Pre-Build, scripts before package building&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; build pre&lt;br /&gt;
        # &amp;lt;&amp;lt; build pre&lt;br /&gt;
&lt;br /&gt;
* Post-Build, scripts after package building&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; build post&lt;br /&gt;
        # &amp;lt;&amp;lt; build post&lt;br /&gt;
&lt;br /&gt;
* Pre-Install, scripts before package installation&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; install pre&lt;br /&gt;
        # &amp;lt;&amp;lt; install pre&lt;br /&gt;
&lt;br /&gt;
* Post-Install, scripts after package installation&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; install post&lt;br /&gt;
        # &amp;lt;&amp;lt; install post&lt;br /&gt;
&lt;br /&gt;
* Files, files list in packaged rpm&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; files [sub-package]&lt;br /&gt;
        # &amp;lt;&amp;lt; files [sub-package]&lt;br /&gt;
NOTE**: &amp;quot;sub-packge&amp;quot; stands for the name of sub-package, and it is optional. If no sub-package name specified, it means the files of **main** package.&lt;br /&gt;
NOTE**: If the file list is simple enough, you can use YAML *Files* keyword instead to record it.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %check section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; check&lt;br /&gt;
        # &amp;lt;&amp;lt; check&lt;br /&gt;
NOTE**: Only if YAML boolean *Check* is specifed as ``yes``, %check with placeholder lines will be generated in .spec.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %pre section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; pre&lt;br /&gt;
        # &amp;lt;&amp;lt; pre&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %preun section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; preun&lt;br /&gt;
        # &amp;lt;&amp;lt; preun&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %post section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; post&lt;br /&gt;
        # &amp;lt;&amp;lt; post&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %postun section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; postun&lt;br /&gt;
        # &amp;lt;&amp;lt; postun&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Internal Implementation ==&lt;br /&gt;
Spectacle uses cheetah templates to generate the spec file, based the metadata&lt;br /&gt;
from YAML file. But the end users need not tackle it.&lt;br /&gt;
&lt;br /&gt;
== Tips ==&lt;br /&gt;
To upgrade the pkg to a newer version, you can just edit the&lt;br /&gt;
version string in spectacle YAML file, and when you run ``specify``, it&lt;br /&gt;
will download the needed files for you automatically.&lt;br /&gt;
&lt;br /&gt;
For packages with locale data, *LocaleName* is needed. If package&lt;br /&gt;
maintainers cannot confirm whether there are locale files, they can just&lt;br /&gt;
do not use *LocaleName* at first, and whenever &amp;quot;unpackaged files&amp;quot; rpm&lt;br /&gt;
packaging errors encountered, it means *LocaleName* should be added. And&lt;br /&gt;
please do not use it for packages without locale data to keep them clean,&lt;br /&gt;
though it will not block the building and packaging.&lt;br /&gt;
&lt;br /&gt;
When using spec2spectacle/ini2spectacle to generate spectacle, the following problems should be checked:&lt;br /&gt;
* Remove duplicate Requires(include pre/post/preun/postun) which were added automatically based on the analysis of file list.&lt;br /&gt;
* Review and clean up the reserved scripts in &amp;quot;build|install pre|post&amp;quot; sections in new generated spec file.&lt;br /&gt;
&lt;br /&gt;
User can use &amp;quot;series.conf&amp;quot; file to specify multiple patches under package directory. The &amp;quot;series.conf&amp;quot; can be used by ``quilt`` and the content can be updated to spec automatically when running ``specify``.&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Spectacle</id>
		<title>Spectacle</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Spectacle"/>
				<updated>2011-02-25T07:32:16Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* Syntax of spectacle YAML */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Spectacle is the toolset for packaging maintenance of MeeGo, including the tool&lt;br /&gt;
to generate spec files from metadata file in YAML format, and tools to convert  &lt;br /&gt;
spec files or spec-builder's ini files to YAML format.                          &lt;br /&gt;
&lt;br /&gt;
For spectacle managed packages, all generic packaging information will be stored&lt;br /&gt;
in the YAML file, and it also allows maintaining customizations in the spec file&lt;br /&gt;
directly with special enclosure tags.                                           &lt;br /&gt;
&lt;br /&gt;
Three separated tools will be installed:&lt;br /&gt;
&lt;br /&gt;
* specify: the tool to generate or to update spec file, based on YAML&lt;br /&gt;
* ini2spectacle: the tool to convert spec-builder .ini to YAML and new spec file&lt;br /&gt;
* spec2spectacle: the tool to convert original spec to YAML and new spec file&lt;br /&gt;
&lt;br /&gt;
== Installation ==&lt;br /&gt;
=== Instruction ===&lt;br /&gt;
Several methods available for spectacle installation:&lt;br /&gt;
&lt;br /&gt;
* Install rpm/deb packages for several supported Linux distributions.&lt;br /&gt;
  From [http://repo.meego.com/tools/repos/ MeeGo Tools Repo], repo urls and install packages can be found for:&lt;br /&gt;
    * MeeGo&lt;br /&gt;
    * Fedora 10,11,12&lt;br /&gt;
    * openSUSE(s)    &lt;br /&gt;
    * xUbuntu 8.10/9.04/9.10/10.04&lt;br /&gt;
    * Debian 5.0            &lt;br /&gt;
&lt;br /&gt;
* Build from the latest source and install it by ``make install``&lt;br /&gt;
  The latest code in git tree can be accessed at:&lt;br /&gt;
  [git://gitorious.org/meego-developer-tools/spectacle.git]&lt;br /&gt;
&lt;br /&gt;
'''Note on Ubuntu installation'''&lt;br /&gt;
From [http://bugs.meego.com/show_bug.cgi?id=6734 this] Edit or create ''/etc/apt/sources.list.d/meego.list'' with sudo&lt;br /&gt;
Add&lt;br /&gt;
 deb http://repo.meego.com/MeeGo/tools/repos/ubuntu/9.10/ /&lt;br /&gt;
&lt;br /&gt;
run the following commands&lt;br /&gt;
 sudo apt-get update&lt;br /&gt;
&lt;br /&gt;
=== Requirements ===&lt;br /&gt;
* python 2.x, above 2.5&lt;br /&gt;
* PyYAML, the python module for YAML parsing&lt;br /&gt;
* cheetah, one popular templating system for python&amp;lt;br&amp;gt;&lt;br /&gt;
    In many linux distributions, the needed package might be &amp;quot;python-cheetah&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
* specify&lt;br /&gt;
    Usage: specify [options] [yaml-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output spec file&lt;br /&gt;
      -s, --skip-scm        Skip to check upstream SCM when specified in YAML&lt;br /&gt;
      -N, --not-download    Do not try to download newer source files&lt;br /&gt;
      -n, --non-interactive&lt;br /&gt;
                              Non interactive running, to use default answers&lt;br /&gt;
       --new=NEWYAML         Create a new yaml from template&lt;br /&gt;
       --newsub=NEWSUB       Append a new sub-package to current yaml&lt;br /&gt;
&lt;br /&gt;
* ini2spectacle&lt;br /&gt;
    Usage: ini2spectacle [options] [ini-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output yaml file&lt;br /&gt;
      -f, --include-files   To store files list in YAML file&lt;br /&gt;
&lt;br /&gt;
* spec2spectacle&lt;br /&gt;
    Usage: spec2spectacle [options] [spec-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output yaml file&lt;br /&gt;
      -r, --replace-macros  To replace self-defined macros in spec file&lt;br /&gt;
      --no-builder-parsing  Do NOT try to parse build/install scripts&lt;br /&gt;
      -f, --include-files   To store files list in YAML file&lt;br /&gt;
&lt;br /&gt;
== Syntax of spectacle YAML ==&lt;br /&gt;
The syntax of YAML can be refered here: &amp;lt;http://www.yaml.org/spec/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Two example spectacle YAML files are placed to examples/ directory in source&lt;br /&gt;
code:&lt;br /&gt;
&lt;br /&gt;
* xfce4-session.yaml, a real world sample with most of the elements&lt;br /&gt;
* general.yaml, a fake spectacle contains all the available elements with comments&lt;br /&gt;
&lt;br /&gt;
All available directives for spectacle are listed as the following:&lt;br /&gt;
&lt;br /&gt;
* Name: **string**&lt;br /&gt;
&lt;br /&gt;
* Summary: **string**&lt;br /&gt;
&lt;br /&gt;
* Version: **string**, version string&lt;br /&gt;
&lt;br /&gt;
* Release: **string**&lt;br /&gt;
&lt;br /&gt;
* Epoch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Group: **string**&lt;br /&gt;
&lt;br /&gt;
* License: **string**&lt;br /&gt;
&lt;br /&gt;
* URL: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* BuildArch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* ExclusiveArch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Prefix: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* LocaleName: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* LocaleOptions: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Description: **text**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Sources: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* SourcePrefix: **string**, *optional*, specify the prefix path in source package&lt;br /&gt;
&lt;br /&gt;
* ExtraSources: **list** of **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* SetupOptions: **string**, *optional*, the options string for %setup&lt;br /&gt;
&lt;br /&gt;
* Patches: **list** of **string**, all patches need to be in 'p1' level&lt;br /&gt;
&lt;br /&gt;
* Requires: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPre: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPreUn: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPost: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPostUn: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* PkgBR: **list** of **string**, packages required in building, or BuildRequires&lt;br /&gt;
&lt;br /&gt;
* PkgConfigBR: **list** of **string**, pkg-config requires in building&lt;br /&gt;
&lt;br /&gt;
* Provides: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Conflicts: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Obsoletes: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* BuildConflicts: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Configure: **string**, *optional*, valid values: **autogen**, **configure**, **reconfigure**, **none**&amp;lt;br&amp;gt;&lt;br /&gt;
** If not specified, the default value &amp;quot;configure&amp;quot; will be used&lt;br /&gt;
&lt;br /&gt;
* ConfigOptions: **list**, *optional*, extra options for ``Configure``&lt;br /&gt;
&lt;br /&gt;
* Builder: **string**, *optional*, valid values: **make**, **single-make**, **python**, **perl**, **qmake**, **none**&amp;lt;br&amp;gt;&lt;br /&gt;
** If not specified, the deault value &amp;quot;make&amp;quot; will be used. If do not want a automatic builder, please use &amp;quot;none&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* QMakeOptions: **list**, *optional*, extra options for **qmake** ``Builder``&lt;br /&gt;
&lt;br /&gt;
* Files: **list** of **string**, *optional*, content of ``%files`` for small packages&lt;br /&gt;
&lt;br /&gt;
* FilesInput: **string**, *optional*, extra input source for %files&lt;br /&gt;
&lt;br /&gt;
* NoFiles: **boolean**, *optional*, if to be set as True, means no %files section for this package and it cause no rpm generated&lt;br /&gt;
&lt;br /&gt;
* RunFdupes: **list** of **string**, paths under %{buildroot} to run ``%fdupes`` macro in %install&lt;br /&gt;
&lt;br /&gt;
* RpmLintIgnore: **list**, *optional*, list of skip items for ``rpmlint``&lt;br /&gt;
&lt;br /&gt;
* Check: **boolean**, whether need ``%check`` section in spec&lt;br /&gt;
&lt;br /&gt;
* SupportOtherDistros: **boolean**, whether need to check for other distros (besides MeeGo)&lt;br /&gt;
&lt;br /&gt;
* UseAsNeeded: **boolean**, whether export LD\_AS\_NEEDED=1 environ variable before building&lt;br /&gt;
&lt;br /&gt;
* NoAutoReq: **boolean**, whether add 'AutoReq: 0' to spec&lt;br /&gt;
&lt;br /&gt;
* NoAutoProv: **boolean**, whether add 'AutoProv: 0' to spec&lt;br /&gt;
&lt;br /&gt;
* NoSetup: **boolean**, whether to skip using ``%setup`` in ``%prep``&lt;br /&gt;
&lt;br /&gt;
* NoAutoLocale: **boolean**, whether to use ``%find_lang`` to search locale data when found 'intltool' in PkgBR&lt;br /&gt;
&lt;br /&gt;
* NoDesktop: **boolean**, whether to install the desktop files in package&lt;br /&gt;
&lt;br /&gt;
* UpdateDesktopDB: **boolean**, whether to run 'update-desktop-database' to flush cache when package (un)installation&lt;br /&gt;
&lt;br /&gt;
* NoIconCache: **boolean**, whether to run 'gtk-update-icon-cache' if icon files found in package&lt;br /&gt;
&lt;br /&gt;
* AutoDepend: **boolean**, for subpackages only, whether to add Require to main package automatically&lt;br /&gt;
&lt;br /&gt;
* AsWholeName: **boolean**, for subpackages only, whether to use **Name** as the whole package name&lt;br /&gt;
&lt;br /&gt;
* AutoSubPackages: **list** of **string**, mainly for '-devel'&lt;br /&gt;
&lt;br /&gt;
* SubPackages: **list** of **dict**, the **dict** item is the lower level directives for sub packages:&lt;br /&gt;
&lt;br /&gt;
    * Name&lt;br /&gt;
    * Summary&lt;br /&gt;
    * Description, *optional*&lt;br /&gt;
    * Group, *optional*&lt;br /&gt;
    * License, *optional*&lt;br /&gt;
    * Requires, *optional*&lt;br /&gt;
    * etc.&lt;br /&gt;
&lt;br /&gt;
'''CAUTION''': The following cases of value string have special meaning in YAML syntax:&lt;br /&gt;
* string with leading **``%``** charactor&lt;br /&gt;
* string with leading **``*``** charactor&lt;br /&gt;
* string contains **``:``** charactor and one or more spaces/tabs after **``:``**&lt;br /&gt;
* string end with **``:``** charactor&lt;br /&gt;
&lt;br /&gt;
Then these string values need to be quoted by ``'``(single-quote) or ``&amp;quot;``&lt;br /&gt;
(double-quote), and the choice of quote char should not conflict with the value&lt;br /&gt;
string self.&lt;br /&gt;
&lt;br /&gt;
== Namespace support for multi-architecture in several keywords ==&lt;br /&gt;
For the following spectacle YAML keywords:&lt;br /&gt;
&lt;br /&gt;
* Requires&lt;br /&gt;
* PkgBR&lt;br /&gt;
* PkgConfigBR&lt;br /&gt;
* Patches&lt;br /&gt;
* ConfigOptions&lt;br /&gt;
* QMakeOptions&lt;br /&gt;
&lt;br /&gt;
If one of the items need to be architecture specified, we can add arch prefix to&lt;br /&gt;
it. The supported prefix and the corresponding architectures as the followings:&lt;br /&gt;
&lt;br /&gt;
* ``ix86:`` -   x86 platform&lt;br /&gt;
* ``arm:``  -   arm platform&lt;br /&gt;
* ``armv5:``  -   armv5 platform, will expand to &amp;quot;armv5el armv5tel armv5tejl&amp;quot;&lt;br /&gt;
* ``armv7:``  -   armv7 platform, will expand to &amp;quot;armv7el armv7tel armv7l armv7hl armv7nhl&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Here's some samples:&lt;br /&gt;
&lt;br /&gt;
    Requires:&lt;br /&gt;
        - arm:pkg-need-in-arm-image&lt;br /&gt;
        - ix86:pkg-need-in-x86-image&lt;br /&gt;
        - normal-pkg&lt;br /&gt;
    ConfigOptions:&lt;br /&gt;
        - arm:--arm-specific-opt&lt;br /&gt;
        - ix86:--ix86-specific-opt&lt;br /&gt;
        - --common-opt&lt;br /&gt;
&lt;br /&gt;
== Customizations in spec ==&lt;br /&gt;
Generated spec files by specify will have many placeholders for customizations,&lt;br /&gt;
such as:&lt;br /&gt;
&lt;br /&gt;
    # &amp;gt;&amp;gt; build pre&lt;br /&gt;
    # &amp;lt;&amp;lt; build pre&lt;br /&gt;
&lt;br /&gt;
You can add any custom code between the markers, next time when you run&lt;br /&gt;
``specify``, the text between the markers will be kept as is, all other sections&lt;br /&gt;
relying on the meta data from the YAML file will be changed depending on the&lt;br /&gt;
values in the YAML file.&lt;br /&gt;
&lt;br /&gt;
The following placeholders in spec can be customized:&lt;br /&gt;
&lt;br /&gt;
* Private Macros, used in this package's spec&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; macros&lt;br /&gt;
        # &amp;lt;&amp;lt; macros&lt;br /&gt;
&lt;br /&gt;
* Extra setup scripts in the last of ``%prep``&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; setup&lt;br /&gt;
        # &amp;lt;&amp;lt; setup&lt;br /&gt;
&lt;br /&gt;
* Pre-Build, scripts before package building&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; build pre&lt;br /&gt;
        # &amp;lt;&amp;lt; build pre&lt;br /&gt;
&lt;br /&gt;
* Post-Build, scripts after package building&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; build post&lt;br /&gt;
        # &amp;lt;&amp;lt; build post&lt;br /&gt;
&lt;br /&gt;
* Pre-Install, scripts before package installation&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; install pre&lt;br /&gt;
        # &amp;lt;&amp;lt; install pre&lt;br /&gt;
&lt;br /&gt;
* Post-Install, scripts after package installation&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; install post&lt;br /&gt;
        # &amp;lt;&amp;lt; install post&lt;br /&gt;
&lt;br /&gt;
* Files, files list in packaged rpm&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; files [sub-package]&lt;br /&gt;
        # &amp;lt;&amp;lt; files [sub-package]&lt;br /&gt;
NOTE**: &amp;quot;sub-packge&amp;quot; stands for the name of sub-package, and it is optional. If no sub-package name specified, it means the files of **main** package.&lt;br /&gt;
NOTE**: If the file list is simple enough, you can use YAML *Files* keyword instead to record it.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %check section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; check&lt;br /&gt;
        # &amp;lt;&amp;lt; check&lt;br /&gt;
NOTE**: Only if YAML boolean *Check* is specifed as ``yes``, %check with placeholder lines will be generated in .spec.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %pre section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; pre&lt;br /&gt;
        # &amp;lt;&amp;lt; pre&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %preun section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; preun&lt;br /&gt;
        # &amp;lt;&amp;lt; preun&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %post section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; post&lt;br /&gt;
        # &amp;lt;&amp;lt; post&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %postun section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; postun&lt;br /&gt;
        # &amp;lt;&amp;lt; postun&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Internal Implementation ==&lt;br /&gt;
Spectacle uses cheetah templates to generate the spec file, based the metadata&lt;br /&gt;
from YAML file. But the end users need not tackle it.&lt;br /&gt;
&lt;br /&gt;
== Tips ==&lt;br /&gt;
To upgrade the pkg to a newer version, you can just edit the&lt;br /&gt;
version string in spectacle YAML file, and when you run ``specify``, it&lt;br /&gt;
will download the needed files for you automatically.&lt;br /&gt;
&lt;br /&gt;
For packages with locale data, *LocaleName* is needed. If package&lt;br /&gt;
maintainers cannot confirm whether there are locale files, they can just&lt;br /&gt;
do not use *LocaleName* at first, and whenever &amp;quot;unpackaged files&amp;quot; rpm&lt;br /&gt;
packaging errors encountered, it means *LocaleName* should be added. And&lt;br /&gt;
please do not use it for packages without locale data to keep them clean,&lt;br /&gt;
though it will not block the building and packaging.&lt;br /&gt;
&lt;br /&gt;
When using spec2spectacle/ini2spectacle to generate spectacle, the following problems should be checked:&lt;br /&gt;
* Remove duplicate Requires(include pre/post/preun/postun) which were added automatically based on the analysis of file list.&lt;br /&gt;
* Review and clean up the reserved scripts in &amp;quot;build|install pre|post&amp;quot; sections in new generated spec file.&lt;br /&gt;
&lt;br /&gt;
User can use &amp;quot;series.conf&amp;quot; file to specify multiple patches under package directory. The &amp;quot;series.conf&amp;quot; can be used by ``quilt`` and the content can be updated to spec automatically when running ``specify``.&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Spectacle</id>
		<title>Spectacle</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Spectacle"/>
				<updated>2011-02-25T07:31:22Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* Namespace support for multi-architecture in several keywords */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Spectacle is the toolset for packaging maintenance of MeeGo, including the tool&lt;br /&gt;
to generate spec files from metadata file in YAML format, and tools to convert  &lt;br /&gt;
spec files or spec-builder's ini files to YAML format.                          &lt;br /&gt;
&lt;br /&gt;
For spectacle managed packages, all generic packaging information will be stored&lt;br /&gt;
in the YAML file, and it also allows maintaining customizations in the spec file&lt;br /&gt;
directly with special enclosure tags.                                           &lt;br /&gt;
&lt;br /&gt;
Three separated tools will be installed:&lt;br /&gt;
&lt;br /&gt;
* specify: the tool to generate or to update spec file, based on YAML&lt;br /&gt;
* ini2spectacle: the tool to convert spec-builder .ini to YAML and new spec file&lt;br /&gt;
* spec2spectacle: the tool to convert original spec to YAML and new spec file&lt;br /&gt;
&lt;br /&gt;
== Installation ==&lt;br /&gt;
=== Instruction ===&lt;br /&gt;
Several methods available for spectacle installation:&lt;br /&gt;
&lt;br /&gt;
* Install rpm/deb packages for several supported Linux distributions.&lt;br /&gt;
  From [http://repo.meego.com/tools/repos/ MeeGo Tools Repo], repo urls and install packages can be found for:&lt;br /&gt;
    * MeeGo&lt;br /&gt;
    * Fedora 10,11,12&lt;br /&gt;
    * openSUSE(s)    &lt;br /&gt;
    * xUbuntu 8.10/9.04/9.10/10.04&lt;br /&gt;
    * Debian 5.0            &lt;br /&gt;
&lt;br /&gt;
* Build from the latest source and install it by ``make install``&lt;br /&gt;
  The latest code in git tree can be accessed at:&lt;br /&gt;
  [git://gitorious.org/meego-developer-tools/spectacle.git]&lt;br /&gt;
&lt;br /&gt;
'''Note on Ubuntu installation'''&lt;br /&gt;
From [http://bugs.meego.com/show_bug.cgi?id=6734 this] Edit or create ''/etc/apt/sources.list.d/meego.list'' with sudo&lt;br /&gt;
Add&lt;br /&gt;
 deb http://repo.meego.com/MeeGo/tools/repos/ubuntu/9.10/ /&lt;br /&gt;
&lt;br /&gt;
run the following commands&lt;br /&gt;
 sudo apt-get update&lt;br /&gt;
&lt;br /&gt;
=== Requirements ===&lt;br /&gt;
* python 2.x, above 2.5&lt;br /&gt;
* PyYAML, the python module for YAML parsing&lt;br /&gt;
* cheetah, one popular templating system for python&amp;lt;br&amp;gt;&lt;br /&gt;
    In many linux distributions, the needed package might be &amp;quot;python-cheetah&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
* specify&lt;br /&gt;
    Usage: specify [options] [yaml-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output spec file&lt;br /&gt;
      -s, --skip-scm        Skip to check upstream SCM when specified in YAML&lt;br /&gt;
      -N, --not-download    Do not try to download newer source files&lt;br /&gt;
      -n, --non-interactive&lt;br /&gt;
                              Non interactive running, to use default answers&lt;br /&gt;
       --new=NEWYAML         Create a new yaml from template&lt;br /&gt;
       --newsub=NEWSUB       Append a new sub-package to current yaml&lt;br /&gt;
&lt;br /&gt;
* ini2spectacle&lt;br /&gt;
    Usage: ini2spectacle [options] [ini-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output yaml file&lt;br /&gt;
      -f, --include-files   To store files list in YAML file&lt;br /&gt;
&lt;br /&gt;
* spec2spectacle&lt;br /&gt;
    Usage: spec2spectacle [options] [spec-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output yaml file&lt;br /&gt;
      -r, --replace-macros  To replace self-defined macros in spec file&lt;br /&gt;
      --no-builder-parsing  Do NOT try to parse build/install scripts&lt;br /&gt;
      -f, --include-files   To store files list in YAML file&lt;br /&gt;
&lt;br /&gt;
== Syntax of spectacle YAML ==&lt;br /&gt;
The syntax of YAML can be refered here: &amp;lt;http://www.yaml.org/spec/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Two example spectacle YAML files are placed to examples/ directory in source&lt;br /&gt;
code:&lt;br /&gt;
&lt;br /&gt;
* xfce4-session.yaml, a real world sample with most of the elements&lt;br /&gt;
* general.yaml, a fake spectacle contains all the available elements with comments&lt;br /&gt;
&lt;br /&gt;
All available directives for spectacle are listed as the following:&lt;br /&gt;
&lt;br /&gt;
* Name: **string**&lt;br /&gt;
&lt;br /&gt;
* Summary: **string**&lt;br /&gt;
&lt;br /&gt;
* Version: **string**, version string&lt;br /&gt;
&lt;br /&gt;
* Release: **string**&lt;br /&gt;
&lt;br /&gt;
* Epoch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Group: **string**&lt;br /&gt;
&lt;br /&gt;
* License: **string**&lt;br /&gt;
&lt;br /&gt;
* URL: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* BuildArch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* ExclusiveArch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Prefix: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* LocaleName: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* LocaleOptions: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Description: **text**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Sources: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* SourcePrefix: **string**, *optional*, specify the prefix path in source package&lt;br /&gt;
&lt;br /&gt;
* ExtraSources: **list** of **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* SetupOptions: **string**, *optional*, the options string for %setup&lt;br /&gt;
&lt;br /&gt;
* Patches: **list** of **string**, all patches need to be in 'p1' level&lt;br /&gt;
&lt;br /&gt;
* Requires: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPre: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPreUn: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPost: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPostUn: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* PkgBR: **list** of **string**, packages required in building, or BuildRequires&lt;br /&gt;
&lt;br /&gt;
* PkgConfigBR: **list** of **string**, pkg-config requires in building&lt;br /&gt;
&lt;br /&gt;
* Provides: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Conflicts: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Obsoletes: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* BuildConflicts: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Configure: **string**, *optional*, valid values: **autogen**, **configure**, **reconfigure**, **none**&amp;lt;br&amp;gt;&lt;br /&gt;
** If not specified, the default value &amp;quot;configure&amp;quot; will be used&lt;br /&gt;
&lt;br /&gt;
* ConfigOptions: **list**, *optional*, extra options for ``Configure``&lt;br /&gt;
&lt;br /&gt;
* Builder: **string**, *optional*, valid values: **make**, **single-make**, **python**, **perl**, **qmake**, **none**&amp;lt;br&amp;gt;&lt;br /&gt;
** If not specified, the deault value &amp;quot;make&amp;quot; will be used. If do not want a automatic builder, please use &amp;quot;none&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* QMakeOptions: **list**, *optional*, extra options for **qmake** ``Builder``&lt;br /&gt;
&lt;br /&gt;
* Files: **list** of **string**, *optional*, content of ``%files`` for small packages&lt;br /&gt;
&lt;br /&gt;
* FilesInput: **string**, *optional*, extra input source for %files&lt;br /&gt;
&lt;br /&gt;
* NoFiles: **boolean**, *optional*, if to be set as True, means no %files section for this package and it cause no rpm generated&lt;br /&gt;
&lt;br /&gt;
* RunFdupes: **list** of **string**, paths under %{buildroot} to run ``%fdupes`` macro in %install&lt;br /&gt;
&lt;br /&gt;
* RpmLintIgnore: **list**, *optional*, list of skip items for ``rpmlint``&lt;br /&gt;
&lt;br /&gt;
* Check: **boolean**, whether need ``%check`` section in spec&lt;br /&gt;
&lt;br /&gt;
* SupportOtherDistros: **boolean**, whether need to check for other distros (besides MeeGo)&lt;br /&gt;
&lt;br /&gt;
* UseAsNeeded: **boolean**, whether export LD\_AS\_NEEDED=1 environ variable before building&lt;br /&gt;
&lt;br /&gt;
* NoAutoReq: **boolean**, whether add 'AutoReq: 0' to spec&lt;br /&gt;
&lt;br /&gt;
* NoAutoProv: **boolean**, whether add 'AutoProv: 0' to spec&lt;br /&gt;
&lt;br /&gt;
* NoSetup: **boolean**, whether to skip using ``%setup`` in ``%prep``&lt;br /&gt;
&lt;br /&gt;
* NoAutoLocale: **boolean**, whether to use ``%find_lang`` to search locale data when found 'intltool' in PkgBR&lt;br /&gt;
&lt;br /&gt;
* NoDesktop: **boolean**, whether to install the desktop files in package&lt;br /&gt;
&lt;br /&gt;
* UpdateDesktopDB: **boolean**, whether to run 'update-desktop-database' to flush cache when package (un)installation&lt;br /&gt;
&lt;br /&gt;
* AutoDepend: **boolean**, for subpackages only, whether to add Require to main package automatically&lt;br /&gt;
&lt;br /&gt;
* AsWholeName: **boolean**, for subpackages only, whether to use **Name** as the whole package name&lt;br /&gt;
&lt;br /&gt;
* AutoSubPackages: **list** of **string**, mainly for '-devel'&lt;br /&gt;
&lt;br /&gt;
* SubPackages: **list** of **dict**, the **dict** item is the lower level directives for sub packages:&lt;br /&gt;
&lt;br /&gt;
    * Name&lt;br /&gt;
    * Summary&lt;br /&gt;
    * Description, *optional*&lt;br /&gt;
    * Group, *optional*&lt;br /&gt;
    * License, *optional*&lt;br /&gt;
    * Requires, *optional*&lt;br /&gt;
    * etc.&lt;br /&gt;
&lt;br /&gt;
'''CAUTION''': The following cases of value string have special meaning in YAML syntax:&lt;br /&gt;
* string with leading **``%``** charactor&lt;br /&gt;
* string with leading **``*``** charactor&lt;br /&gt;
* string contains **``:``** charactor and one or more spaces/tabs after **``:``**&lt;br /&gt;
* string end with **``:``** charactor&lt;br /&gt;
&lt;br /&gt;
Then these string values need to be quoted by ``'``(single-quote) or ``&amp;quot;``&lt;br /&gt;
(double-quote), and the choice of quote char should not conflict with the value&lt;br /&gt;
string self.&lt;br /&gt;
&lt;br /&gt;
== Namespace support for multi-architecture in several keywords ==&lt;br /&gt;
For the following spectacle YAML keywords:&lt;br /&gt;
&lt;br /&gt;
* Requires&lt;br /&gt;
* PkgBR&lt;br /&gt;
* PkgConfigBR&lt;br /&gt;
* Patches&lt;br /&gt;
* ConfigOptions&lt;br /&gt;
* QMakeOptions&lt;br /&gt;
&lt;br /&gt;
If one of the items need to be architecture specified, we can add arch prefix to&lt;br /&gt;
it. The supported prefix and the corresponding architectures as the followings:&lt;br /&gt;
&lt;br /&gt;
* ``ix86:`` -   x86 platform&lt;br /&gt;
* ``arm:``  -   arm platform&lt;br /&gt;
* ``armv5:``  -   armv5 platform, will expand to &amp;quot;armv5el armv5tel armv5tejl&amp;quot;&lt;br /&gt;
* ``armv7:``  -   armv7 platform, will expand to &amp;quot;armv7el armv7tel armv7l armv7hl armv7nhl&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Here's some samples:&lt;br /&gt;
&lt;br /&gt;
    Requires:&lt;br /&gt;
        - arm:pkg-need-in-arm-image&lt;br /&gt;
        - ix86:pkg-need-in-x86-image&lt;br /&gt;
        - normal-pkg&lt;br /&gt;
    ConfigOptions:&lt;br /&gt;
        - arm:--arm-specific-opt&lt;br /&gt;
        - ix86:--ix86-specific-opt&lt;br /&gt;
        - --common-opt&lt;br /&gt;
&lt;br /&gt;
== Customizations in spec ==&lt;br /&gt;
Generated spec files by specify will have many placeholders for customizations,&lt;br /&gt;
such as:&lt;br /&gt;
&lt;br /&gt;
    # &amp;gt;&amp;gt; build pre&lt;br /&gt;
    # &amp;lt;&amp;lt; build pre&lt;br /&gt;
&lt;br /&gt;
You can add any custom code between the markers, next time when you run&lt;br /&gt;
``specify``, the text between the markers will be kept as is, all other sections&lt;br /&gt;
relying on the meta data from the YAML file will be changed depending on the&lt;br /&gt;
values in the YAML file.&lt;br /&gt;
&lt;br /&gt;
The following placeholders in spec can be customized:&lt;br /&gt;
&lt;br /&gt;
* Private Macros, used in this package's spec&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; macros&lt;br /&gt;
        # &amp;lt;&amp;lt; macros&lt;br /&gt;
&lt;br /&gt;
* Extra setup scripts in the last of ``%prep``&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; setup&lt;br /&gt;
        # &amp;lt;&amp;lt; setup&lt;br /&gt;
&lt;br /&gt;
* Pre-Build, scripts before package building&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; build pre&lt;br /&gt;
        # &amp;lt;&amp;lt; build pre&lt;br /&gt;
&lt;br /&gt;
* Post-Build, scripts after package building&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; build post&lt;br /&gt;
        # &amp;lt;&amp;lt; build post&lt;br /&gt;
&lt;br /&gt;
* Pre-Install, scripts before package installation&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; install pre&lt;br /&gt;
        # &amp;lt;&amp;lt; install pre&lt;br /&gt;
&lt;br /&gt;
* Post-Install, scripts after package installation&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; install post&lt;br /&gt;
        # &amp;lt;&amp;lt; install post&lt;br /&gt;
&lt;br /&gt;
* Files, files list in packaged rpm&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; files [sub-package]&lt;br /&gt;
        # &amp;lt;&amp;lt; files [sub-package]&lt;br /&gt;
NOTE**: &amp;quot;sub-packge&amp;quot; stands for the name of sub-package, and it is optional. If no sub-package name specified, it means the files of **main** package.&lt;br /&gt;
NOTE**: If the file list is simple enough, you can use YAML *Files* keyword instead to record it.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %check section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; check&lt;br /&gt;
        # &amp;lt;&amp;lt; check&lt;br /&gt;
NOTE**: Only if YAML boolean *Check* is specifed as ``yes``, %check with placeholder lines will be generated in .spec.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %pre section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; pre&lt;br /&gt;
        # &amp;lt;&amp;lt; pre&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %preun section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; preun&lt;br /&gt;
        # &amp;lt;&amp;lt; preun&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %post section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; post&lt;br /&gt;
        # &amp;lt;&amp;lt; post&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %postun section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; postun&lt;br /&gt;
        # &amp;lt;&amp;lt; postun&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Internal Implementation ==&lt;br /&gt;
Spectacle uses cheetah templates to generate the spec file, based the metadata&lt;br /&gt;
from YAML file. But the end users need not tackle it.&lt;br /&gt;
&lt;br /&gt;
== Tips ==&lt;br /&gt;
To upgrade the pkg to a newer version, you can just edit the&lt;br /&gt;
version string in spectacle YAML file, and when you run ``specify``, it&lt;br /&gt;
will download the needed files for you automatically.&lt;br /&gt;
&lt;br /&gt;
For packages with locale data, *LocaleName* is needed. If package&lt;br /&gt;
maintainers cannot confirm whether there are locale files, they can just&lt;br /&gt;
do not use *LocaleName* at first, and whenever &amp;quot;unpackaged files&amp;quot; rpm&lt;br /&gt;
packaging errors encountered, it means *LocaleName* should be added. And&lt;br /&gt;
please do not use it for packages without locale data to keep them clean,&lt;br /&gt;
though it will not block the building and packaging.&lt;br /&gt;
&lt;br /&gt;
When using spec2spectacle/ini2spectacle to generate spectacle, the following problems should be checked:&lt;br /&gt;
* Remove duplicate Requires(include pre/post/preun/postun) which were added automatically based on the analysis of file list.&lt;br /&gt;
* Review and clean up the reserved scripts in &amp;quot;build|install pre|post&amp;quot; sections in new generated spec file.&lt;br /&gt;
&lt;br /&gt;
User can use &amp;quot;series.conf&amp;quot; file to specify multiple patches under package directory. The &amp;quot;series.conf&amp;quot; can be used by ``quilt`` and the content can be updated to spec automatically when running ``specify``.&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Quality/Compliance_tools</id>
		<title>Quality/Compliance tools</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Quality/Compliance_tools"/>
				<updated>2010-12-13T10:44:22Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* Image Preparation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Introduction =&lt;br /&gt;
&lt;br /&gt;
Compliance tools are used to check MeeGo compliance for MeeGo Distributions or MeeGo Applications. The compliance reference input is the MeeGo core package/file list and a minimal MeeGo reference image created by MIC2, which will contain all the required core packages, as well as src rpms.&lt;br /&gt;
&lt;br /&gt;
For MeeGo distribution compliance checking, the input needs to include the OS image and the src.rpms for all the packages. And for MeeGo Application compliance checking, the input is the application rpm file.&lt;br /&gt;
&lt;br /&gt;
The tools will generate report files (in HTML currently) to show the result.&lt;br /&gt;
&lt;br /&gt;
= Installation =&lt;br /&gt;
Compliance tools can be installed using released rpm and deb packages, or installed by source code.&lt;br /&gt;
&lt;br /&gt;
== Packages and Repos ==&lt;br /&gt;
The package in the MeeGo OBS server for this project is [http://build.meego.com/package/show?package=meego-compliance-tools&amp;amp;project=devel:tools:building devel:tools:building/meego-compliance-tools]. And all the rpm and deb packages for release can be generated by the MeeGo OBS server. The following Linux distributions are supported:&lt;br /&gt;
&lt;br /&gt;
* Debian 5.0&lt;br /&gt;
* xUbuntu 9.10, 10.04, 10.10&lt;br /&gt;
* Fedora 11, 12, 13&lt;br /&gt;
* openSUSE 11.1, 11.2, 11.3&lt;br /&gt;
* MeeGo 1.0, Trunk (1.2)&lt;br /&gt;
&lt;br /&gt;
All the corresponding package repos can be used to install the tools conveniently,and will be published in http://repo.meego.com.&lt;br /&gt;
&lt;br /&gt;
For rpm packaging ditros, there are three packages available:&lt;br /&gt;
* meego-compliance-tools (common data, will be installed automatically as the dependency of the two packages below)&lt;br /&gt;
* meego-dist-compliance-tools (for MeeGo distro compliance checking)&lt;br /&gt;
* meego-app-compliance-tools. (for MeeGo application compliance checking)&lt;br /&gt;
&lt;br /&gt;
== Source Code ==&lt;br /&gt;
The tools can also be installed by source code. After fetching the code, under the code directory, run:&lt;br /&gt;
  $ [sudo] make install&lt;br /&gt;
&lt;br /&gt;
The source code is hosted at:&lt;br /&gt;
  [http://meego.gitorious.org/meego-developer-tools/meego-compliance-tools meego-compliance-tools@gitorious.org]&lt;br /&gt;
&lt;br /&gt;
== MIC2 ==&lt;br /&gt;
To prepare the images used in compliance tools, you need [[Image_Creation|MIC2]] with new features (version 0.22.0 or later).&lt;br /&gt;
&lt;br /&gt;
=  Features =&lt;br /&gt;
== dist-compliance-tool ==&lt;br /&gt;
It executes compliance checking for MeeGo distributions. The following features are supported:&lt;br /&gt;
* Binary pkg comparison:&lt;br /&gt;
** Exist in target image?&lt;br /&gt;
** Version matches the requirement?&lt;br /&gt;
*** flexible version checking: support rules with comparison operators like &amp;quot;&amp;gt;=&amp;quot; in core pkg list&lt;br /&gt;
* Content in source rpm comparison:&lt;br /&gt;
** This step will be skipped if binary rpm checking fails&lt;br /&gt;
** Spec filename&lt;br /&gt;
** Spec content&lt;br /&gt;
** Sources and md5sum&lt;br /&gt;
** Patches and the content&lt;br /&gt;
&lt;br /&gt;
== app-compliance-tool ==&lt;br /&gt;
For compliance checking for MeeGo applications, the following features are supported:&lt;br /&gt;
* check if all dependent packages exist in core package list&lt;br /&gt;
* check if the target package can be installed in the minimal image&lt;br /&gt;
* verify the installation location of the application&lt;br /&gt;
* verify the minimal requirement of the desktop file and icon for the application&lt;br /&gt;
&lt;br /&gt;
= Usage =&lt;br /&gt;
== Image Preparation ==&lt;br /&gt;
Before using the tools, the reference image needs to be created by using MIC2 (version 0.22.0 or later):&lt;br /&gt;
  $ [sudo] mic-image-creator --run-mode=0 --cache=mycachedir --format=fs  --config=&amp;lt;ks file&amp;gt; --package=tar.bz2 --include-source&lt;br /&gt;
The sample ks file can be downloaded at:&lt;br /&gt;
  [[media:Meego-minimal-compliance-1.0.99.1.ks]]&lt;br /&gt;
The sample core list file can be downloaded at:&lt;br /&gt;
  [[media:Core-list-1.0.99.1‎]]&lt;br /&gt;
And the ks file and core list should be synced with and conform to the latest [[Quality/Compliance|MeeGo compliance spec]].&lt;br /&gt;
&lt;br /&gt;
To use the dist compliance check tool (dist_compliance), the needed target image can also be generated by mic2 using the above options. But the target images&lt;br /&gt;
will not be limited to this specific format(fs in tar.bz2). If the exist target image is in other formats, please unpack it to a directory manually using format&lt;br /&gt;
specific instructions and use this directory as the command line input.&lt;br /&gt;
&lt;br /&gt;
== Devices Compliance Check ==&lt;br /&gt;
The command &amp;quot;dist_complianc&amp;quot; is for checking compliance of MeeGo devices, or distributions.&lt;br /&gt;
&lt;br /&gt;
    Usage: [sudo] dist_compliance [options]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                            File to store core list of MeeGo&lt;br /&gt;
      -r REF, --reference=REF&lt;br /&gt;
                            Path of reference image or unpacked directory&lt;br /&gt;
      -t TGT, --target=TGT  Path of target image or unpacked directory&lt;br /&gt;
      -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                            Output directory of report&lt;br /&gt;
      -d, --debug           Save intermedia log data for debugging&lt;br /&gt;
&lt;br /&gt;
== Apps Compliance Check ==&lt;br /&gt;
The command &amp;quot;app_compliance&amp;quot; is for applications compliance checking.&lt;br /&gt;
&lt;br /&gt;
    Usage: [sudo] app_compliance [options] &amp;lt;app-rpm&amp;gt;&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -r REFIMAGE, --refimage=REFIMAGE&lt;br /&gt;
                            Filepath of reference image&lt;br /&gt;
      -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                            File to store core list of MeeGo&lt;br /&gt;
      -m MEEGO_API_PKGLIST, --meego_api_pkglist=MEEGO_API_PKGLIST&lt;br /&gt;
                            File to store MeeGo API package list of MeeGo&lt;br /&gt;
      -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                            Output directory of report&lt;br /&gt;
      -d, --debug           Save intermedia log data for debugging&lt;br /&gt;
&lt;br /&gt;
The sample MeeGo API package list file can be downloaded at: &lt;br /&gt;
    [[media:MeeGo-API-pkglist.txt]]&lt;br /&gt;
&lt;br /&gt;
= Result Format =&lt;br /&gt;
Currently, the output of checking tools will be store in HTML files.&lt;br /&gt;
Screen capture of sample distribution report:&lt;br /&gt;
[[File:DistSummaryReport.png|none|600px|Sample Report]]&lt;br /&gt;
&lt;br /&gt;
= Bug Reoprt =&lt;br /&gt;
&lt;br /&gt;
If problems were found in compliance tools, please file bugs in bugs.meego.com.&lt;br /&gt;
The corresponding section is: &amp;quot;Development Tools/Tools&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
= TODO =&lt;br /&gt;
&lt;br /&gt;
* add checking for contents of binary packages&lt;br /&gt;
* use new image format with separated src.rpm pack&lt;br /&gt;
* Web UI for commenting the result&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Quality/Compliance_tools</id>
		<title>Quality/Compliance tools</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Quality/Compliance_tools"/>
				<updated>2010-12-13T10:32:23Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* TODO */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Introduction =&lt;br /&gt;
&lt;br /&gt;
Compliance tools are used to check MeeGo compliance for MeeGo Distributions or MeeGo Applications. The compliance reference input is the MeeGo core package/file list and a minimal MeeGo reference image created by MIC2, which will contain all the required core packages, as well as src rpms.&lt;br /&gt;
&lt;br /&gt;
For MeeGo distribution compliance checking, the input needs to include the OS image and the src.rpms for all the packages. And for MeeGo Application compliance checking, the input is the application rpm file.&lt;br /&gt;
&lt;br /&gt;
The tools will generate report files (in HTML currently) to show the result.&lt;br /&gt;
&lt;br /&gt;
= Installation =&lt;br /&gt;
Compliance tools can be installed using released rpm and deb packages, or installed by source code.&lt;br /&gt;
&lt;br /&gt;
== Packages and Repos ==&lt;br /&gt;
The package in the MeeGo OBS server for this project is [http://build.meego.com/package/show?package=meego-compliance-tools&amp;amp;project=devel:tools:building devel:tools:building/meego-compliance-tools]. And all the rpm and deb packages for release can be generated by the MeeGo OBS server. The following Linux distributions are supported:&lt;br /&gt;
&lt;br /&gt;
* Debian 5.0&lt;br /&gt;
* xUbuntu 9.10, 10.04, 10.10&lt;br /&gt;
* Fedora 11, 12, 13&lt;br /&gt;
* openSUSE 11.1, 11.2, 11.3&lt;br /&gt;
* MeeGo 1.0, Trunk (1.2)&lt;br /&gt;
&lt;br /&gt;
All the corresponding package repos can be used to install the tools conveniently,and will be published in http://repo.meego.com.&lt;br /&gt;
&lt;br /&gt;
For rpm packaging ditros, there are three packages available:&lt;br /&gt;
* meego-compliance-tools (common data, will be installed automatically as the dependency of the two packages below)&lt;br /&gt;
* meego-dist-compliance-tools (for MeeGo distro compliance checking)&lt;br /&gt;
* meego-app-compliance-tools. (for MeeGo application compliance checking)&lt;br /&gt;
&lt;br /&gt;
== Source Code ==&lt;br /&gt;
The tools can also be installed by source code. After fetching the code, under the code directory, run:&lt;br /&gt;
  $ [sudo] make install&lt;br /&gt;
&lt;br /&gt;
The source code is hosted at:&lt;br /&gt;
  [http://meego.gitorious.org/meego-developer-tools/meego-compliance-tools meego-compliance-tools@gitorious.org]&lt;br /&gt;
&lt;br /&gt;
== MIC2 ==&lt;br /&gt;
To prepare the images used in compliance tools, you need [[Image_Creation|MIC2]] with new features (version 0.22.0 or later).&lt;br /&gt;
&lt;br /&gt;
=  Features =&lt;br /&gt;
== dist-compliance-tool ==&lt;br /&gt;
It executes compliance checking for MeeGo distributions. The following features are supported:&lt;br /&gt;
* Binary pkg comparison:&lt;br /&gt;
** Exist in target image?&lt;br /&gt;
** Version matches the requirement?&lt;br /&gt;
*** flexible version checking: support rules with comparison operators like &amp;quot;&amp;gt;=&amp;quot; in core pkg list&lt;br /&gt;
* Content in source rpm comparison:&lt;br /&gt;
** This step will be skipped if binary rpm checking fails&lt;br /&gt;
** Spec filename&lt;br /&gt;
** Spec content&lt;br /&gt;
** Sources and md5sum&lt;br /&gt;
** Patches and the content&lt;br /&gt;
&lt;br /&gt;
== app-compliance-tool ==&lt;br /&gt;
For compliance checking for MeeGo applications, the following features are supported:&lt;br /&gt;
* check if all dependent packages exist in core package list&lt;br /&gt;
* check if the target package can be installed in the minimal image&lt;br /&gt;
* verify the installation location of the application&lt;br /&gt;
* verify the minimal requirement of the desktop file and icon for the application&lt;br /&gt;
&lt;br /&gt;
= Usage =&lt;br /&gt;
== Image Preparation ==&lt;br /&gt;
Before using the tools, the reference image needs to be created by using MIC2 (version 0.22.0 or later):&lt;br /&gt;
  $ [sudo] mic-image-creator --run-mode=0 --cache=mycachedir --format=fs  --config=&amp;lt;ks file&amp;gt; --package=tar.bz2 --include-source&lt;br /&gt;
The sample ks file can be downloaded at:&lt;br /&gt;
  [[media:Meego-minimal-compliance-1.0.99.1.ks]]&lt;br /&gt;
The sample core list file can be downloaded at:&lt;br /&gt;
  [[media:Core-list-1.0.99.1‎]]&lt;br /&gt;
And the ks file and core list should be synced with and conform to the latest [[Quality/Compliance|MeeGo compliance spec]].&lt;br /&gt;
&lt;br /&gt;
To try the dist compliance check tool (dist_compliance), please prepare a target image as the input. The target image can be generated using the same method as the above.&lt;br /&gt;
&lt;br /&gt;
== Devices Compliance Check ==&lt;br /&gt;
The command &amp;quot;dist_complianc&amp;quot; is for checking compliance of MeeGo devices, or distributions.&lt;br /&gt;
&lt;br /&gt;
    Usage: [sudo] dist_compliance [options]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                            File to store core list of MeeGo&lt;br /&gt;
      -r REF, --reference=REF&lt;br /&gt;
                            Path of reference image or unpacked directory&lt;br /&gt;
      -t TGT, --target=TGT  Path of target image or unpacked directory&lt;br /&gt;
      -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                            Output directory of report&lt;br /&gt;
      -d, --debug           Save intermedia log data for debugging&lt;br /&gt;
&lt;br /&gt;
== Apps Compliance Check ==&lt;br /&gt;
The command &amp;quot;app_compliance&amp;quot; is for applications compliance checking.&lt;br /&gt;
&lt;br /&gt;
    Usage: [sudo] app_compliance [options] &amp;lt;app-rpm&amp;gt;&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -r REFIMAGE, --refimage=REFIMAGE&lt;br /&gt;
                            Filepath of reference image&lt;br /&gt;
      -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                            File to store core list of MeeGo&lt;br /&gt;
      -m MEEGO_API_PKGLIST, --meego_api_pkglist=MEEGO_API_PKGLIST&lt;br /&gt;
                            File to store MeeGo API package list of MeeGo&lt;br /&gt;
      -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                            Output directory of report&lt;br /&gt;
      -d, --debug           Save intermedia log data for debugging&lt;br /&gt;
&lt;br /&gt;
The sample MeeGo API package list file can be downloaded at: &lt;br /&gt;
    [[media:MeeGo-API-pkglist.txt]]&lt;br /&gt;
&lt;br /&gt;
= Result Format =&lt;br /&gt;
Currently, the output of checking tools will be store in HTML files.&lt;br /&gt;
Screen capture of sample distribution report:&lt;br /&gt;
[[File:DistSummaryReport.png|none|600px|Sample Report]]&lt;br /&gt;
&lt;br /&gt;
= Bug Reoprt =&lt;br /&gt;
&lt;br /&gt;
If problems were found in compliance tools, please file bugs in bugs.meego.com.&lt;br /&gt;
The corresponding section is: &amp;quot;Development Tools/Tools&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
= TODO =&lt;br /&gt;
&lt;br /&gt;
* add checking for contents of binary packages&lt;br /&gt;
* use new image format with separated src.rpm pack&lt;br /&gt;
* Web UI for commenting the result&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Quality/Compliance_tools</id>
		<title>Quality/Compliance tools</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Quality/Compliance_tools"/>
				<updated>2010-12-13T10:31:43Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* Apps Compliance Check */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Introduction =&lt;br /&gt;
&lt;br /&gt;
Compliance tools are used to check MeeGo compliance for MeeGo Distributions or MeeGo Applications. The compliance reference input is the MeeGo core package/file list and a minimal MeeGo reference image created by MIC2, which will contain all the required core packages, as well as src rpms.&lt;br /&gt;
&lt;br /&gt;
For MeeGo distribution compliance checking, the input needs to include the OS image and the src.rpms for all the packages. And for MeeGo Application compliance checking, the input is the application rpm file.&lt;br /&gt;
&lt;br /&gt;
The tools will generate report files (in HTML currently) to show the result.&lt;br /&gt;
&lt;br /&gt;
= Installation =&lt;br /&gt;
Compliance tools can be installed using released rpm and deb packages, or installed by source code.&lt;br /&gt;
&lt;br /&gt;
== Packages and Repos ==&lt;br /&gt;
The package in the MeeGo OBS server for this project is [http://build.meego.com/package/show?package=meego-compliance-tools&amp;amp;project=devel:tools:building devel:tools:building/meego-compliance-tools]. And all the rpm and deb packages for release can be generated by the MeeGo OBS server. The following Linux distributions are supported:&lt;br /&gt;
&lt;br /&gt;
* Debian 5.0&lt;br /&gt;
* xUbuntu 9.10, 10.04, 10.10&lt;br /&gt;
* Fedora 11, 12, 13&lt;br /&gt;
* openSUSE 11.1, 11.2, 11.3&lt;br /&gt;
* MeeGo 1.0, Trunk (1.2)&lt;br /&gt;
&lt;br /&gt;
All the corresponding package repos can be used to install the tools conveniently,and will be published in http://repo.meego.com.&lt;br /&gt;
&lt;br /&gt;
For rpm packaging ditros, there are three packages available:&lt;br /&gt;
* meego-compliance-tools (common data, will be installed automatically as the dependency of the two packages below)&lt;br /&gt;
* meego-dist-compliance-tools (for MeeGo distro compliance checking)&lt;br /&gt;
* meego-app-compliance-tools. (for MeeGo application compliance checking)&lt;br /&gt;
&lt;br /&gt;
== Source Code ==&lt;br /&gt;
The tools can also be installed by source code. After fetching the code, under the code directory, run:&lt;br /&gt;
  $ [sudo] make install&lt;br /&gt;
&lt;br /&gt;
The source code is hosted at:&lt;br /&gt;
  [http://meego.gitorious.org/meego-developer-tools/meego-compliance-tools meego-compliance-tools@gitorious.org]&lt;br /&gt;
&lt;br /&gt;
== MIC2 ==&lt;br /&gt;
To prepare the images used in compliance tools, you need [[Image_Creation|MIC2]] with new features (version 0.22.0 or later).&lt;br /&gt;
&lt;br /&gt;
=  Features =&lt;br /&gt;
== dist-compliance-tool ==&lt;br /&gt;
It executes compliance checking for MeeGo distributions. The following features are supported:&lt;br /&gt;
* Binary pkg comparison:&lt;br /&gt;
** Exist in target image?&lt;br /&gt;
** Version matches the requirement?&lt;br /&gt;
*** flexible version checking: support rules with comparison operators like &amp;quot;&amp;gt;=&amp;quot; in core pkg list&lt;br /&gt;
* Content in source rpm comparison:&lt;br /&gt;
** This step will be skipped if binary rpm checking fails&lt;br /&gt;
** Spec filename&lt;br /&gt;
** Spec content&lt;br /&gt;
** Sources and md5sum&lt;br /&gt;
** Patches and the content&lt;br /&gt;
&lt;br /&gt;
== app-compliance-tool ==&lt;br /&gt;
For compliance checking for MeeGo applications, the following features are supported:&lt;br /&gt;
* check if all dependent packages exist in core package list&lt;br /&gt;
* check if the target package can be installed in the minimal image&lt;br /&gt;
* verify the installation location of the application&lt;br /&gt;
* verify the minimal requirement of the desktop file and icon for the application&lt;br /&gt;
&lt;br /&gt;
= Usage =&lt;br /&gt;
== Image Preparation ==&lt;br /&gt;
Before using the tools, the reference image needs to be created by using MIC2 (version 0.22.0 or later):&lt;br /&gt;
  $ [sudo] mic-image-creator --run-mode=0 --cache=mycachedir --format=fs  --config=&amp;lt;ks file&amp;gt; --package=tar.bz2 --include-source&lt;br /&gt;
The sample ks file can be downloaded at:&lt;br /&gt;
  [[media:Meego-minimal-compliance-1.0.99.1.ks]]&lt;br /&gt;
The sample core list file can be downloaded at:&lt;br /&gt;
  [[media:Core-list-1.0.99.1‎]]&lt;br /&gt;
And the ks file and core list should be synced with and conform to the latest [[Quality/Compliance|MeeGo compliance spec]].&lt;br /&gt;
&lt;br /&gt;
To try the dist compliance check tool (dist_compliance), please prepare a target image as the input. The target image can be generated using the same method as the above.&lt;br /&gt;
&lt;br /&gt;
== Devices Compliance Check ==&lt;br /&gt;
The command &amp;quot;dist_complianc&amp;quot; is for checking compliance of MeeGo devices, or distributions.&lt;br /&gt;
&lt;br /&gt;
    Usage: [sudo] dist_compliance [options]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                            File to store core list of MeeGo&lt;br /&gt;
      -r REF, --reference=REF&lt;br /&gt;
                            Path of reference image or unpacked directory&lt;br /&gt;
      -t TGT, --target=TGT  Path of target image or unpacked directory&lt;br /&gt;
      -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                            Output directory of report&lt;br /&gt;
      -d, --debug           Save intermedia log data for debugging&lt;br /&gt;
&lt;br /&gt;
== Apps Compliance Check ==&lt;br /&gt;
The command &amp;quot;app_compliance&amp;quot; is for applications compliance checking.&lt;br /&gt;
&lt;br /&gt;
    Usage: [sudo] app_compliance [options] &amp;lt;app-rpm&amp;gt;&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -r REFIMAGE, --refimage=REFIMAGE&lt;br /&gt;
                            Filepath of reference image&lt;br /&gt;
      -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                            File to store core list of MeeGo&lt;br /&gt;
      -m MEEGO_API_PKGLIST, --meego_api_pkglist=MEEGO_API_PKGLIST&lt;br /&gt;
                            File to store MeeGo API package list of MeeGo&lt;br /&gt;
      -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                            Output directory of report&lt;br /&gt;
      -d, --debug           Save intermedia log data for debugging&lt;br /&gt;
&lt;br /&gt;
The sample MeeGo API package list file can be downloaded at: &lt;br /&gt;
    [[media:MeeGo-API-pkglist.txt]]&lt;br /&gt;
&lt;br /&gt;
= Result Format =&lt;br /&gt;
Currently, the output of checking tools will be store in HTML files.&lt;br /&gt;
Screen capture of sample distribution report:&lt;br /&gt;
[[File:DistSummaryReport.png|none|600px|Sample Report]]&lt;br /&gt;
&lt;br /&gt;
= Bug Reoprt =&lt;br /&gt;
&lt;br /&gt;
If problems were found in compliance tools, please file bugs in bugs.meego.com.&lt;br /&gt;
The corresponding section is: &amp;quot;Development Tools/Tools&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
= TODO =&lt;br /&gt;
&lt;br /&gt;
* add checking for contents of binary packages&lt;br /&gt;
* architecture re-design and code update&lt;br /&gt;
* use new image format with separated src.rpm pack&lt;br /&gt;
* web UI&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Quality/Compliance_tools</id>
		<title>Quality/Compliance tools</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Quality/Compliance_tools"/>
				<updated>2010-12-13T10:30:32Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* Devices Compliance Check */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Introduction =&lt;br /&gt;
&lt;br /&gt;
Compliance tools are used to check MeeGo compliance for MeeGo Distributions or MeeGo Applications. The compliance reference input is the MeeGo core package/file list and a minimal MeeGo reference image created by MIC2, which will contain all the required core packages, as well as src rpms.&lt;br /&gt;
&lt;br /&gt;
For MeeGo distribution compliance checking, the input needs to include the OS image and the src.rpms for all the packages. And for MeeGo Application compliance checking, the input is the application rpm file.&lt;br /&gt;
&lt;br /&gt;
The tools will generate report files (in HTML currently) to show the result.&lt;br /&gt;
&lt;br /&gt;
= Installation =&lt;br /&gt;
Compliance tools can be installed using released rpm and deb packages, or installed by source code.&lt;br /&gt;
&lt;br /&gt;
== Packages and Repos ==&lt;br /&gt;
The package in the MeeGo OBS server for this project is [http://build.meego.com/package/show?package=meego-compliance-tools&amp;amp;project=devel:tools:building devel:tools:building/meego-compliance-tools]. And all the rpm and deb packages for release can be generated by the MeeGo OBS server. The following Linux distributions are supported:&lt;br /&gt;
&lt;br /&gt;
* Debian 5.0&lt;br /&gt;
* xUbuntu 9.10, 10.04, 10.10&lt;br /&gt;
* Fedora 11, 12, 13&lt;br /&gt;
* openSUSE 11.1, 11.2, 11.3&lt;br /&gt;
* MeeGo 1.0, Trunk (1.2)&lt;br /&gt;
&lt;br /&gt;
All the corresponding package repos can be used to install the tools conveniently,and will be published in http://repo.meego.com.&lt;br /&gt;
&lt;br /&gt;
For rpm packaging ditros, there are three packages available:&lt;br /&gt;
* meego-compliance-tools (common data, will be installed automatically as the dependency of the two packages below)&lt;br /&gt;
* meego-dist-compliance-tools (for MeeGo distro compliance checking)&lt;br /&gt;
* meego-app-compliance-tools. (for MeeGo application compliance checking)&lt;br /&gt;
&lt;br /&gt;
== Source Code ==&lt;br /&gt;
The tools can also be installed by source code. After fetching the code, under the code directory, run:&lt;br /&gt;
  $ [sudo] make install&lt;br /&gt;
&lt;br /&gt;
The source code is hosted at:&lt;br /&gt;
  [http://meego.gitorious.org/meego-developer-tools/meego-compliance-tools meego-compliance-tools@gitorious.org]&lt;br /&gt;
&lt;br /&gt;
== MIC2 ==&lt;br /&gt;
To prepare the images used in compliance tools, you need [[Image_Creation|MIC2]] with new features (version 0.22.0 or later).&lt;br /&gt;
&lt;br /&gt;
=  Features =&lt;br /&gt;
== dist-compliance-tool ==&lt;br /&gt;
It executes compliance checking for MeeGo distributions. The following features are supported:&lt;br /&gt;
* Binary pkg comparison:&lt;br /&gt;
** Exist in target image?&lt;br /&gt;
** Version matches the requirement?&lt;br /&gt;
*** flexible version checking: support rules with comparison operators like &amp;quot;&amp;gt;=&amp;quot; in core pkg list&lt;br /&gt;
* Content in source rpm comparison:&lt;br /&gt;
** This step will be skipped if binary rpm checking fails&lt;br /&gt;
** Spec filename&lt;br /&gt;
** Spec content&lt;br /&gt;
** Sources and md5sum&lt;br /&gt;
** Patches and the content&lt;br /&gt;
&lt;br /&gt;
== app-compliance-tool ==&lt;br /&gt;
For compliance checking for MeeGo applications, the following features are supported:&lt;br /&gt;
* check if all dependent packages exist in core package list&lt;br /&gt;
* check if the target package can be installed in the minimal image&lt;br /&gt;
* verify the installation location of the application&lt;br /&gt;
* verify the minimal requirement of the desktop file and icon for the application&lt;br /&gt;
&lt;br /&gt;
= Usage =&lt;br /&gt;
== Image Preparation ==&lt;br /&gt;
Before using the tools, the reference image needs to be created by using MIC2 (version 0.22.0 or later):&lt;br /&gt;
  $ [sudo] mic-image-creator --run-mode=0 --cache=mycachedir --format=fs  --config=&amp;lt;ks file&amp;gt; --package=tar.bz2 --include-source&lt;br /&gt;
The sample ks file can be downloaded at:&lt;br /&gt;
  [[media:Meego-minimal-compliance-1.0.99.1.ks]]&lt;br /&gt;
The sample core list file can be downloaded at:&lt;br /&gt;
  [[media:Core-list-1.0.99.1‎]]&lt;br /&gt;
And the ks file and core list should be synced with and conform to the latest [[Quality/Compliance|MeeGo compliance spec]].&lt;br /&gt;
&lt;br /&gt;
To try the dist compliance check tool (dist_compliance), please prepare a target image as the input. The target image can be generated using the same method as the above.&lt;br /&gt;
&lt;br /&gt;
== Devices Compliance Check ==&lt;br /&gt;
The command &amp;quot;dist_complianc&amp;quot; is for checking compliance of MeeGo devices, or distributions.&lt;br /&gt;
&lt;br /&gt;
    Usage: [sudo] dist_compliance [options]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                            File to store core list of MeeGo&lt;br /&gt;
      -r REF, --reference=REF&lt;br /&gt;
                            Path of reference image or unpacked directory&lt;br /&gt;
      -t TGT, --target=TGT  Path of target image or unpacked directory&lt;br /&gt;
      -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                            Output directory of report&lt;br /&gt;
      -d, --debug           Save intermedia log data for debugging&lt;br /&gt;
&lt;br /&gt;
== Apps Compliance Check ==&lt;br /&gt;
The command &amp;quot;app_compliance&amp;quot; is for applications compliance checking.&lt;br /&gt;
&lt;br /&gt;
    Usage: [sudo] app_compliance [options] &amp;lt;app-rpm&amp;gt;&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -r REFIMAGE, --refimage=REFIMAGE&lt;br /&gt;
                            Filepath of reference image&lt;br /&gt;
      -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                            File to store core list of MeeGo&lt;br /&gt;
      -m MEEGO_API_PKGLIST, --meego_api_pkglist=MEEGO_API_PKGLIST&lt;br /&gt;
                            File to store MeeGo API package list of MeeGo&lt;br /&gt;
      -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                            Output directory of report&lt;br /&gt;
The sample MeeGo API package list file can be downloaded at: &lt;br /&gt;
    [[media:MeeGo-API-pkglist.txt]]&lt;br /&gt;
&lt;br /&gt;
= Result Format =&lt;br /&gt;
Currently, the output of checking tools will be store in HTML files.&lt;br /&gt;
Screen capture of sample distribution report:&lt;br /&gt;
[[File:DistSummaryReport.png|none|600px|Sample Report]]&lt;br /&gt;
&lt;br /&gt;
= Bug Reoprt =&lt;br /&gt;
&lt;br /&gt;
If problems were found in compliance tools, please file bugs in bugs.meego.com.&lt;br /&gt;
The corresponding section is: &amp;quot;Development Tools/Tools&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
= TODO =&lt;br /&gt;
&lt;br /&gt;
* add checking for contents of binary packages&lt;br /&gt;
* architecture re-design and code update&lt;br /&gt;
* use new image format with separated src.rpm pack&lt;br /&gt;
* web UI&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Quality/Compliance_tools</id>
		<title>Quality/Compliance tools</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Quality/Compliance_tools"/>
				<updated>2010-12-13T10:29:29Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* Image Preparation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Introduction =&lt;br /&gt;
&lt;br /&gt;
Compliance tools are used to check MeeGo compliance for MeeGo Distributions or MeeGo Applications. The compliance reference input is the MeeGo core package/file list and a minimal MeeGo reference image created by MIC2, which will contain all the required core packages, as well as src rpms.&lt;br /&gt;
&lt;br /&gt;
For MeeGo distribution compliance checking, the input needs to include the OS image and the src.rpms for all the packages. And for MeeGo Application compliance checking, the input is the application rpm file.&lt;br /&gt;
&lt;br /&gt;
The tools will generate report files (in HTML currently) to show the result.&lt;br /&gt;
&lt;br /&gt;
= Installation =&lt;br /&gt;
Compliance tools can be installed using released rpm and deb packages, or installed by source code.&lt;br /&gt;
&lt;br /&gt;
== Packages and Repos ==&lt;br /&gt;
The package in the MeeGo OBS server for this project is [http://build.meego.com/package/show?package=meego-compliance-tools&amp;amp;project=devel:tools:building devel:tools:building/meego-compliance-tools]. And all the rpm and deb packages for release can be generated by the MeeGo OBS server. The following Linux distributions are supported:&lt;br /&gt;
&lt;br /&gt;
* Debian 5.0&lt;br /&gt;
* xUbuntu 9.10, 10.04, 10.10&lt;br /&gt;
* Fedora 11, 12, 13&lt;br /&gt;
* openSUSE 11.1, 11.2, 11.3&lt;br /&gt;
* MeeGo 1.0, Trunk (1.2)&lt;br /&gt;
&lt;br /&gt;
All the corresponding package repos can be used to install the tools conveniently,and will be published in http://repo.meego.com.&lt;br /&gt;
&lt;br /&gt;
For rpm packaging ditros, there are three packages available:&lt;br /&gt;
* meego-compliance-tools (common data, will be installed automatically as the dependency of the two packages below)&lt;br /&gt;
* meego-dist-compliance-tools (for MeeGo distro compliance checking)&lt;br /&gt;
* meego-app-compliance-tools. (for MeeGo application compliance checking)&lt;br /&gt;
&lt;br /&gt;
== Source Code ==&lt;br /&gt;
The tools can also be installed by source code. After fetching the code, under the code directory, run:&lt;br /&gt;
  $ [sudo] make install&lt;br /&gt;
&lt;br /&gt;
The source code is hosted at:&lt;br /&gt;
  [http://meego.gitorious.org/meego-developer-tools/meego-compliance-tools meego-compliance-tools@gitorious.org]&lt;br /&gt;
&lt;br /&gt;
== MIC2 ==&lt;br /&gt;
To prepare the images used in compliance tools, you need [[Image_Creation|MIC2]] with new features (version 0.22.0 or later).&lt;br /&gt;
&lt;br /&gt;
=  Features =&lt;br /&gt;
== dist-compliance-tool ==&lt;br /&gt;
It executes compliance checking for MeeGo distributions. The following features are supported:&lt;br /&gt;
* Binary pkg comparison:&lt;br /&gt;
** Exist in target image?&lt;br /&gt;
** Version matches the requirement?&lt;br /&gt;
*** flexible version checking: support rules with comparison operators like &amp;quot;&amp;gt;=&amp;quot; in core pkg list&lt;br /&gt;
* Content in source rpm comparison:&lt;br /&gt;
** This step will be skipped if binary rpm checking fails&lt;br /&gt;
** Spec filename&lt;br /&gt;
** Spec content&lt;br /&gt;
** Sources and md5sum&lt;br /&gt;
** Patches and the content&lt;br /&gt;
&lt;br /&gt;
== app-compliance-tool ==&lt;br /&gt;
For compliance checking for MeeGo applications, the following features are supported:&lt;br /&gt;
* check if all dependent packages exist in core package list&lt;br /&gt;
* check if the target package can be installed in the minimal image&lt;br /&gt;
* verify the installation location of the application&lt;br /&gt;
* verify the minimal requirement of the desktop file and icon for the application&lt;br /&gt;
&lt;br /&gt;
= Usage =&lt;br /&gt;
== Image Preparation ==&lt;br /&gt;
Before using the tools, the reference image needs to be created by using MIC2 (version 0.22.0 or later):&lt;br /&gt;
  $ [sudo] mic-image-creator --run-mode=0 --cache=mycachedir --format=fs  --config=&amp;lt;ks file&amp;gt; --package=tar.bz2 --include-source&lt;br /&gt;
The sample ks file can be downloaded at:&lt;br /&gt;
  [[media:Meego-minimal-compliance-1.0.99.1.ks]]&lt;br /&gt;
The sample core list file can be downloaded at:&lt;br /&gt;
  [[media:Core-list-1.0.99.1‎]]&lt;br /&gt;
And the ks file and core list should be synced with and conform to the latest [[Quality/Compliance|MeeGo compliance spec]].&lt;br /&gt;
&lt;br /&gt;
To try the dist compliance check tool (dist_compliance), please prepare a target image as the input. The target image can be generated using the same method as the above.&lt;br /&gt;
&lt;br /&gt;
== Devices Compliance Check ==&lt;br /&gt;
The command &amp;quot;dist_complianc&amp;quot; is for checking compliance of MeeGo devices, or distributions.&lt;br /&gt;
&lt;br /&gt;
     Usage: [sudo] dist_compliance [options]&lt;br /&gt;
     Options:&lt;br /&gt;
        --version             show program's version number and exit&lt;br /&gt;
        -h, --help            show this help message and exit&lt;br /&gt;
        -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                              File to store core list of MeeGo&lt;br /&gt;
        -r REFIMAGE, --refimage=REFIMAGE&lt;br /&gt;
                              Filepath of reference image&lt;br /&gt;
        -t TGTIMAGE, --tgtimage=TGTIMAGE&lt;br /&gt;
                              Filepath of target image&lt;br /&gt;
        -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                              Output directory of report&lt;br /&gt;
&lt;br /&gt;
== Apps Compliance Check ==&lt;br /&gt;
The command &amp;quot;app_compliance&amp;quot; is for applications compliance checking.&lt;br /&gt;
&lt;br /&gt;
    Usage: [sudo] app_compliance [options] &amp;lt;app-rpm&amp;gt;&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -r REFIMAGE, --refimage=REFIMAGE&lt;br /&gt;
                            Filepath of reference image&lt;br /&gt;
      -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                            File to store core list of MeeGo&lt;br /&gt;
      -m MEEGO_API_PKGLIST, --meego_api_pkglist=MEEGO_API_PKGLIST&lt;br /&gt;
                            File to store MeeGo API package list of MeeGo&lt;br /&gt;
      -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                            Output directory of report&lt;br /&gt;
The sample MeeGo API package list file can be downloaded at: &lt;br /&gt;
    [[media:MeeGo-API-pkglist.txt]]&lt;br /&gt;
&lt;br /&gt;
= Result Format =&lt;br /&gt;
Currently, the output of checking tools will be store in HTML files.&lt;br /&gt;
Screen capture of sample distribution report:&lt;br /&gt;
[[File:DistSummaryReport.png|none|600px|Sample Report]]&lt;br /&gt;
&lt;br /&gt;
= Bug Reoprt =&lt;br /&gt;
&lt;br /&gt;
If problems were found in compliance tools, please file bugs in bugs.meego.com.&lt;br /&gt;
The corresponding section is: &amp;quot;Development Tools/Tools&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
= TODO =&lt;br /&gt;
&lt;br /&gt;
* add checking for contents of binary packages&lt;br /&gt;
* architecture re-design and code update&lt;br /&gt;
* use new image format with separated src.rpm pack&lt;br /&gt;
* web UI&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Quality/Compliance_tools</id>
		<title>Quality/Compliance tools</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Quality/Compliance_tools"/>
				<updated>2010-12-13T10:28:04Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* Packages and Repos */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Introduction =&lt;br /&gt;
&lt;br /&gt;
Compliance tools are used to check MeeGo compliance for MeeGo Distributions or MeeGo Applications. The compliance reference input is the MeeGo core package/file list and a minimal MeeGo reference image created by MIC2, which will contain all the required core packages, as well as src rpms.&lt;br /&gt;
&lt;br /&gt;
For MeeGo distribution compliance checking, the input needs to include the OS image and the src.rpms for all the packages. And for MeeGo Application compliance checking, the input is the application rpm file.&lt;br /&gt;
&lt;br /&gt;
The tools will generate report files (in HTML currently) to show the result.&lt;br /&gt;
&lt;br /&gt;
= Installation =&lt;br /&gt;
Compliance tools can be installed using released rpm and deb packages, or installed by source code.&lt;br /&gt;
&lt;br /&gt;
== Packages and Repos ==&lt;br /&gt;
The package in the MeeGo OBS server for this project is [http://build.meego.com/package/show?package=meego-compliance-tools&amp;amp;project=devel:tools:building devel:tools:building/meego-compliance-tools]. And all the rpm and deb packages for release can be generated by the MeeGo OBS server. The following Linux distributions are supported:&lt;br /&gt;
&lt;br /&gt;
* Debian 5.0&lt;br /&gt;
* xUbuntu 9.10, 10.04, 10.10&lt;br /&gt;
* Fedora 11, 12, 13&lt;br /&gt;
* openSUSE 11.1, 11.2, 11.3&lt;br /&gt;
* MeeGo 1.0, Trunk (1.2)&lt;br /&gt;
&lt;br /&gt;
All the corresponding package repos can be used to install the tools conveniently,and will be published in http://repo.meego.com.&lt;br /&gt;
&lt;br /&gt;
For rpm packaging ditros, there are three packages available:&lt;br /&gt;
* meego-compliance-tools (common data, will be installed automatically as the dependency of the two packages below)&lt;br /&gt;
* meego-dist-compliance-tools (for MeeGo distro compliance checking)&lt;br /&gt;
* meego-app-compliance-tools. (for MeeGo application compliance checking)&lt;br /&gt;
&lt;br /&gt;
== Source Code ==&lt;br /&gt;
The tools can also be installed by source code. After fetching the code, under the code directory, run:&lt;br /&gt;
  $ [sudo] make install&lt;br /&gt;
&lt;br /&gt;
The source code is hosted at:&lt;br /&gt;
  [http://meego.gitorious.org/meego-developer-tools/meego-compliance-tools meego-compliance-tools@gitorious.org]&lt;br /&gt;
&lt;br /&gt;
== MIC2 ==&lt;br /&gt;
To prepare the images used in compliance tools, you need [[Image_Creation|MIC2]] with new features (version 0.22.0 or later).&lt;br /&gt;
&lt;br /&gt;
=  Features =&lt;br /&gt;
== dist-compliance-tool ==&lt;br /&gt;
It executes compliance checking for MeeGo distributions. The following features are supported:&lt;br /&gt;
* Binary pkg comparison:&lt;br /&gt;
** Exist in target image?&lt;br /&gt;
** Version matches the requirement?&lt;br /&gt;
*** flexible version checking: support rules with comparison operators like &amp;quot;&amp;gt;=&amp;quot; in core pkg list&lt;br /&gt;
* Content in source rpm comparison:&lt;br /&gt;
** This step will be skipped if binary rpm checking fails&lt;br /&gt;
** Spec filename&lt;br /&gt;
** Spec content&lt;br /&gt;
** Sources and md5sum&lt;br /&gt;
** Patches and the content&lt;br /&gt;
&lt;br /&gt;
== app-compliance-tool ==&lt;br /&gt;
For compliance checking for MeeGo applications, the following features are supported:&lt;br /&gt;
* check if all dependent packages exist in core package list&lt;br /&gt;
* check if the target package can be installed in the minimal image&lt;br /&gt;
* verify the installation location of the application&lt;br /&gt;
* verify the minimal requirement of the desktop file and icon for the application&lt;br /&gt;
&lt;br /&gt;
= Usage =&lt;br /&gt;
== Image Preparation ==&lt;br /&gt;
Before using the tools, the reference image needs to be created by using MIC2 (version 0.22.0 or later):&lt;br /&gt;
  $ [sudo] mic-image-creator --run-mode=0 --cache=mycachedir --format=fs  --config=&amp;lt;ks file&amp;gt; --package=tar.bz2 --include-source&lt;br /&gt;
The sample ks file can be downloaded at:&lt;br /&gt;
  [[media:Meego-minimal-compliance-1.0.99.1.ks]]&lt;br /&gt;
The sample core list file can be downloaded at:&lt;br /&gt;
  [[media:Core-list-1.0.99.1‎]]&lt;br /&gt;
And the ks file and core list should be synced with and conform to the latest [[Quality/Compliance|MeeGo compliance spec]].&lt;br /&gt;
&lt;br /&gt;
To try the dist compliance check tool (dist_compliance.sh), please prepare a target image as the input. The target image can be generated by using the same method as the above.&lt;br /&gt;
&lt;br /&gt;
== Devices Compliance Check ==&lt;br /&gt;
The command &amp;quot;dist_complianc&amp;quot; is for checking compliance of MeeGo devices, or distributions.&lt;br /&gt;
&lt;br /&gt;
     Usage: [sudo] dist_compliance [options]&lt;br /&gt;
     Options:&lt;br /&gt;
        --version             show program's version number and exit&lt;br /&gt;
        -h, --help            show this help message and exit&lt;br /&gt;
        -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                              File to store core list of MeeGo&lt;br /&gt;
        -r REFIMAGE, --refimage=REFIMAGE&lt;br /&gt;
                              Filepath of reference image&lt;br /&gt;
        -t TGTIMAGE, --tgtimage=TGTIMAGE&lt;br /&gt;
                              Filepath of target image&lt;br /&gt;
        -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                              Output directory of report&lt;br /&gt;
&lt;br /&gt;
== Apps Compliance Check ==&lt;br /&gt;
The command &amp;quot;app_compliance&amp;quot; is for applications compliance checking.&lt;br /&gt;
&lt;br /&gt;
    Usage: [sudo] app_compliance [options] &amp;lt;app-rpm&amp;gt;&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -r REFIMAGE, --refimage=REFIMAGE&lt;br /&gt;
                            Filepath of reference image&lt;br /&gt;
      -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                            File to store core list of MeeGo&lt;br /&gt;
      -m MEEGO_API_PKGLIST, --meego_api_pkglist=MEEGO_API_PKGLIST&lt;br /&gt;
                            File to store MeeGo API package list of MeeGo&lt;br /&gt;
      -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                            Output directory of report&lt;br /&gt;
The sample MeeGo API package list file can be downloaded at: &lt;br /&gt;
    [[media:MeeGo-API-pkglist.txt]]&lt;br /&gt;
&lt;br /&gt;
= Result Format =&lt;br /&gt;
Currently, the output of checking tools will be store in HTML files.&lt;br /&gt;
Screen capture of sample distribution report:&lt;br /&gt;
[[File:DistSummaryReport.png|none|600px|Sample Report]]&lt;br /&gt;
&lt;br /&gt;
= Bug Reoprt =&lt;br /&gt;
&lt;br /&gt;
If problems were found in compliance tools, please file bugs in bugs.meego.com.&lt;br /&gt;
The corresponding section is: &amp;quot;Development Tools/Tools&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
= TODO =&lt;br /&gt;
&lt;br /&gt;
* add checking for contents of binary packages&lt;br /&gt;
* architecture re-design and code update&lt;br /&gt;
* use new image format with separated src.rpm pack&lt;br /&gt;
* web UI&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Spectacle</id>
		<title>Spectacle</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Spectacle"/>
				<updated>2010-11-25T04:33:27Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Spectacle is the toolset for packaging maintenance of MeeGo, including the tool&lt;br /&gt;
to generate spec files from metadata file in YAML format, and tools to convert  &lt;br /&gt;
spec files or spec-builder's ini files to YAML format.                          &lt;br /&gt;
&lt;br /&gt;
For spectacle managed packages, all generic packaging information will be stored&lt;br /&gt;
in the YAML file, and it also allows maintaining customizations in the spec file&lt;br /&gt;
directly with special enclosure tags.                                           &lt;br /&gt;
&lt;br /&gt;
Three separated tools will be installed:&lt;br /&gt;
&lt;br /&gt;
* specify: the tool to generate or to update spec file, based on YAML&lt;br /&gt;
* ini2spectacle: the tool to convert spec-builder .ini to YAML and new spec file&lt;br /&gt;
* spec2spectacle: the tool to convert original spec to YAML and new spec file&lt;br /&gt;
&lt;br /&gt;
== Installation ==&lt;br /&gt;
=== Instruction ===&lt;br /&gt;
Several methods available for spectacle installation:&lt;br /&gt;
&lt;br /&gt;
* Install rpm/deb packages for several supported Linux distributions.&lt;br /&gt;
  From [http://repo.meego.com/tools/repos/ MeeGo Tools Repo], repo urls and install packages can be found for:&lt;br /&gt;
    * MeeGo&lt;br /&gt;
    * Fedora 10,11,12&lt;br /&gt;
    * openSUSE(s)    &lt;br /&gt;
    * xUbuntu 8.10/9.04/9.10/10.04&lt;br /&gt;
    * Debian 5.0            &lt;br /&gt;
&lt;br /&gt;
* Build from the latest source and install it by ``make install``&lt;br /&gt;
  The latest code in git tree can be accessed at:&lt;br /&gt;
  [git://gitorious.org/meego-developer-tools/spectacle.git]&lt;br /&gt;
&lt;br /&gt;
'''Note on Ubuntu installation'''&lt;br /&gt;
From [http://bugs.meego.com/show_bug.cgi?id=6734 this] Edit or create ''/etc/apt/sources.list.d/meego.list'' with sudo&lt;br /&gt;
Add&lt;br /&gt;
 deb http://repo.meego.com/MeeGo/tools/repos/ubuntu/9.10/ /&lt;br /&gt;
&lt;br /&gt;
run the following commands&lt;br /&gt;
 sudo apt-get update&lt;br /&gt;
&lt;br /&gt;
=== Requirements ===&lt;br /&gt;
* python 2.x, above 2.5&lt;br /&gt;
* PyYAML, the python module for YAML parsing&lt;br /&gt;
* cheetah, one popular templating system for python&amp;lt;br&amp;gt;&lt;br /&gt;
    In many linux distributions, the needed package might be &amp;quot;python-cheetah&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
* specify&lt;br /&gt;
    Usage: specify [options] [yaml-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output spec file&lt;br /&gt;
      -s, --skip-scm        Skip to check upstream SCM when specified in YAML&lt;br /&gt;
      -N, --not-download    Do not try to download newer source files&lt;br /&gt;
      -n, --non-interactive&lt;br /&gt;
                              Non interactive running, to use default answers&lt;br /&gt;
       --new=NEWYAML         Create a new yaml from template&lt;br /&gt;
       --newsub=NEWSUB       Append a new sub-package to current yaml&lt;br /&gt;
&lt;br /&gt;
* ini2spectacle&lt;br /&gt;
    Usage: ini2spectacle [options] [ini-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output yaml file&lt;br /&gt;
      -f, --include-files   To store files list in YAML file&lt;br /&gt;
&lt;br /&gt;
* spec2spectacle&lt;br /&gt;
    Usage: spec2spectacle [options] [spec-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output yaml file&lt;br /&gt;
      -r, --replace-macros  To replace self-defined macros in spec file&lt;br /&gt;
      --no-builder-parsing  Do NOT try to parse build/install scripts&lt;br /&gt;
      -f, --include-files   To store files list in YAML file&lt;br /&gt;
&lt;br /&gt;
== Syntax of spectacle YAML ==&lt;br /&gt;
The syntax of YAML can be refered here: &amp;lt;http://www.yaml.org/spec/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Two example spectacle YAML files are placed to examples/ directory in source&lt;br /&gt;
code:&lt;br /&gt;
&lt;br /&gt;
* xfce4-session.yaml, a real world sample with most of the elements&lt;br /&gt;
* general.yaml, a fake spectacle contains all the available elements with comments&lt;br /&gt;
&lt;br /&gt;
All available directives for spectacle are listed as the following:&lt;br /&gt;
&lt;br /&gt;
* Name: **string**&lt;br /&gt;
&lt;br /&gt;
* Summary: **string**&lt;br /&gt;
&lt;br /&gt;
* Version: **string**, version string&lt;br /&gt;
&lt;br /&gt;
* Release: **string**&lt;br /&gt;
&lt;br /&gt;
* Epoch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Group: **string**&lt;br /&gt;
&lt;br /&gt;
* License: **string**&lt;br /&gt;
&lt;br /&gt;
* URL: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* BuildArch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* ExclusiveArch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Prefix: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* LocaleName: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* LocaleOptions: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Description: **text**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Sources: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* SourcePrefix: **string**, *optional*, specify the prefix path in source package&lt;br /&gt;
&lt;br /&gt;
* ExtraSources: **list** of **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* SetupOptions: **string**, *optional*, the options string for %setup&lt;br /&gt;
&lt;br /&gt;
* Patches: **list** of **string**, all patches need to be in 'p1' level&lt;br /&gt;
&lt;br /&gt;
* Requires: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPre: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPreUn: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPost: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPostUn: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* PkgBR: **list** of **string**, packages required in building, or BuildRequires&lt;br /&gt;
&lt;br /&gt;
* PkgConfigBR: **list** of **string**, pkg-config requires in building&lt;br /&gt;
&lt;br /&gt;
* Provides: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Conflicts: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Obsoletes: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* BuildConflicts: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Configure: **string**, *optional*, valid values: **autogen**, **configure**,&lt;br /&gt;
  **reconfigure**, **none**&amp;lt;br&amp;gt;&lt;br /&gt;
  **If not specified, the default value &amp;quot;configure&amp;quot; will be used**&lt;br /&gt;
&lt;br /&gt;
* ConfigOptions: **list**, *optional*, extra options for ``Configure``&lt;br /&gt;
&lt;br /&gt;
* Builder: **string**, *optional*, valid values: **make**, **single-make**,&lt;br /&gt;
  **python**, **perl**, **qmake**, **none**&amp;lt;br&amp;gt;&lt;br /&gt;
  **If not specified, the deault value &amp;quot;make&amp;quot; will be used. If do not want a&lt;br /&gt;
  automatic builder, please use &amp;quot;none&amp;quot;.**&lt;br /&gt;
&lt;br /&gt;
* QMakeOptions: **list**, *optional*, extra options for **qmake** ``Builder``&lt;br /&gt;
&lt;br /&gt;
* Files: **list** of **string**, *optional*, content of ``%files`` for small packages&lt;br /&gt;
&lt;br /&gt;
* FilesInput: **string**, *optional*, extra input source for %files&lt;br /&gt;
&lt;br /&gt;
* NoFiles: **boolean**, *optional*, if to be set as True, means no %files section for this package and it cause no rpm generated&lt;br /&gt;
&lt;br /&gt;
* RunFdupes: **list** of **string**, paths under %{buildroot} to run ``%fdupes`` macro in %install&lt;br /&gt;
&lt;br /&gt;
* RpmLintIgnore: **list**, *optional*, list of skip items for ``rpmlint``&lt;br /&gt;
&lt;br /&gt;
* Check: **boolean**, whether need ``%check`` section in spec&lt;br /&gt;
&lt;br /&gt;
* SupportOtherDistros: **boolean**, whether need to check for other distros (besides MeeGo)&lt;br /&gt;
&lt;br /&gt;
* UseAsNeeded: **boolean**, whether export LD\_AS\_NEEDED=1 environ variable before building&lt;br /&gt;
&lt;br /&gt;
* NoAutoReq: **boolean**, whether add 'AutoReq: 0' to spec&lt;br /&gt;
&lt;br /&gt;
* NoAutoProv: **boolean**, whether add 'AutoProv: 0' to spec&lt;br /&gt;
&lt;br /&gt;
* NoSetup: **boolean**, whether to skip using ``%setup`` in ``%prep``&lt;br /&gt;
&lt;br /&gt;
* NoAutoLocale: **boolean**, whether to use ``%find_lang`` to search locale data when found 'intltool' in PkgBR&lt;br /&gt;
&lt;br /&gt;
* NoDesktop: **boolean**, whether to install the desktop files in package&lt;br /&gt;
&lt;br /&gt;
* UpdateDesktopDB: **boolean**, whether to run 'update-desktop-database' to flush cache when package (un)installation&lt;br /&gt;
&lt;br /&gt;
* AutoDepend: **boolean**, for subpackages only, whether to add Require to main package automatically&lt;br /&gt;
&lt;br /&gt;
* AsWholeName: **boolean**, for subpackages only, whether to use **Name** as the whole package name&lt;br /&gt;
&lt;br /&gt;
* AutoSubPackages: **list** of **string**, mainly for '-devel'&lt;br /&gt;
&lt;br /&gt;
* SubPackages: **list** of **dict**, the **dict** item is the lower level&lt;br /&gt;
directives for sub packages:&lt;br /&gt;
&lt;br /&gt;
    * Name&lt;br /&gt;
    * Summary&lt;br /&gt;
    * Description, *optional*&lt;br /&gt;
    * Group, *optional*&lt;br /&gt;
    * License, *optional*&lt;br /&gt;
    * Requires, *optional*&lt;br /&gt;
    * etc.&lt;br /&gt;
&lt;br /&gt;
**CAUTION**: The following cases of value string have special meaning in YAML syntax:&lt;br /&gt;
&lt;br /&gt;
* string with leading **``%``** charactor&lt;br /&gt;
* string with leading **``*``** charactor&lt;br /&gt;
* string contains **``:``** charactor and one or more spaces/tabs after **``:``**&lt;br /&gt;
* string end with **``:``** charactor&lt;br /&gt;
&lt;br /&gt;
Then these string values need to be quoted by ``'``(single-quote) or ``&amp;quot;``&lt;br /&gt;
(double-quote), and the choice of quote char should not conflict with the value&lt;br /&gt;
string self.&lt;br /&gt;
&lt;br /&gt;
== Namespace support for multi-architecture in several keywords ==&lt;br /&gt;
For the following spectacle YAML keywords:&lt;br /&gt;
&lt;br /&gt;
* Requires&lt;br /&gt;
* PkgBR&lt;br /&gt;
* PkgConfigBR&lt;br /&gt;
* Patches&lt;br /&gt;
* ConfigOptions&lt;br /&gt;
* QMakeOptions&lt;br /&gt;
&lt;br /&gt;
If one of the items need to be architecture specified, we can add arch prefix to&lt;br /&gt;
it. The supported prefix and the corresponding architectures as the followings:&lt;br /&gt;
&lt;br /&gt;
* ``ix86:`` -   x86 platform&lt;br /&gt;
* ``arm:``  -   arm platform&lt;br /&gt;
&lt;br /&gt;
Here's some samples:&lt;br /&gt;
&lt;br /&gt;
    Requires:&lt;br /&gt;
        - arm:pkg-need-in-arm-image&lt;br /&gt;
        - ix86:pkg-need-in-x86-image&lt;br /&gt;
        - normal-pkg&lt;br /&gt;
    ConfigOptions:&lt;br /&gt;
        - arm:--arm-specific-opt&lt;br /&gt;
        - ix86:--ix86-specific-opt&lt;br /&gt;
        - --common-opt&lt;br /&gt;
&lt;br /&gt;
== Customizations in spec ==&lt;br /&gt;
Generated spec files by specify will have many placeholders for customizations,&lt;br /&gt;
such as:&lt;br /&gt;
&lt;br /&gt;
    # &amp;gt;&amp;gt; build pre&lt;br /&gt;
    # &amp;lt;&amp;lt; build pre&lt;br /&gt;
&lt;br /&gt;
You can add any custom code between the markers, next time when you run&lt;br /&gt;
``specify``, the text between the markers will be kept as is, all other sections&lt;br /&gt;
relying on the meta data from the YAML file will be changed depending on the&lt;br /&gt;
values in the YAML file.&lt;br /&gt;
&lt;br /&gt;
The following placeholders in spec can be customized:&lt;br /&gt;
&lt;br /&gt;
* Private Macros, used in this package's spec&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; macros&lt;br /&gt;
        # &amp;lt;&amp;lt; macros&lt;br /&gt;
&lt;br /&gt;
* Extra setup scripts in the last of ``%prep``&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; setup&lt;br /&gt;
        # &amp;lt;&amp;lt; setup&lt;br /&gt;
&lt;br /&gt;
* Pre-Build, scripts before package building&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; build pre&lt;br /&gt;
        # &amp;lt;&amp;lt; build pre&lt;br /&gt;
&lt;br /&gt;
* Post-Build, scripts after package building&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; build post&lt;br /&gt;
        # &amp;lt;&amp;lt; build post&lt;br /&gt;
&lt;br /&gt;
* Pre-Install, scripts before package installation&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; install pre&lt;br /&gt;
        # &amp;lt;&amp;lt; install pre&lt;br /&gt;
&lt;br /&gt;
* Post-Install, scripts after package installation&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; install post&lt;br /&gt;
        # &amp;lt;&amp;lt; install post&lt;br /&gt;
&lt;br /&gt;
* Files, files list in packaged rpm&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; files [sub-package]&lt;br /&gt;
        # &amp;lt;&amp;lt; files [sub-package]&lt;br /&gt;
NOTE**: &amp;quot;sub-packge&amp;quot; stands for the name of sub-package, and it is optional. If no sub-package name specified, it means the files of **main** package.&lt;br /&gt;
NOTE**: If the file list is simple enough, you can use YAML *Files* keyword instead to record it.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %check section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; check&lt;br /&gt;
        # &amp;lt;&amp;lt; check&lt;br /&gt;
NOTE**: Only if YAML boolean *Check* is specifed as ``yes``, %check with placeholder lines will be generated in .spec.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %pre section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; pre&lt;br /&gt;
        # &amp;lt;&amp;lt; pre&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %preun section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; preun&lt;br /&gt;
        # &amp;lt;&amp;lt; preun&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %post section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; post&lt;br /&gt;
        # &amp;lt;&amp;lt; post&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %postun section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; postun&lt;br /&gt;
        # &amp;lt;&amp;lt; postun&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Internal Implementation ==&lt;br /&gt;
Spectacle uses cheetah templates to generate the spec file, based the metadata&lt;br /&gt;
from YAML file. But the end users need not tackle it.&lt;br /&gt;
&lt;br /&gt;
== Tips ==&lt;br /&gt;
* If to upgrade the pkg to a newer version, you can just edit the&lt;br /&gt;
version string in spectacle YAML file, and when you run ``specify``, it&lt;br /&gt;
will download the needed files for you automatically.&lt;br /&gt;
&lt;br /&gt;
* For packages with locale data, *LocaleName* is needed. If package&lt;br /&gt;
maintainers cannot confirm whether there are locale files, they can just&lt;br /&gt;
do not use *LocaleName* at first, and whenever &amp;quot;unpackaged files&amp;quot; rpm&lt;br /&gt;
packaging errors encountered, it means *LocaleName* should be added. And&lt;br /&gt;
please do not use it for packages without locale data to keep them clean,&lt;br /&gt;
though it will not block the building and packaging.&lt;br /&gt;
&lt;br /&gt;
* When using spec2spectacle/ini2spectacle to generate spectacle, the following problems should be checked:&lt;br /&gt;
&lt;br /&gt;
     * Remove duplicate Requires(include pre/post/preun/postun) which were added automatically based on the analysis of file list.&lt;br /&gt;
     * Review and clean up the reserved scripts in &amp;quot;build|install pre|post&amp;quot; sections in new generated spec file.&lt;br /&gt;
&lt;br /&gt;
* User can use &amp;quot;series.conf&amp;quot; file to specify multiple patches under package directory. The &amp;quot;series.conf&amp;quot; can be used by ``quilt`` and the content can be updated to spec automatically when running ``specify``.&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Spectacle</id>
		<title>Spectacle</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Spectacle"/>
				<updated>2010-11-25T04:27:35Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* Namespace support for multi-architecture in several keywords */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Spectacle is the toolset for packaging maintenance of MeeGo, including the tool&lt;br /&gt;
to generate spec files from metadata file in YAML format, and tools to convert  &lt;br /&gt;
spec files or spec-builder's ini files to YAML format.                          &lt;br /&gt;
&lt;br /&gt;
For spectacle managed packages, all generic packaging information will be stored&lt;br /&gt;
in the YAML file, and it also allows maintaining customizations in the spec file&lt;br /&gt;
directly with special enclosure tags.                                           &lt;br /&gt;
&lt;br /&gt;
Three separated tools will be installed:&lt;br /&gt;
&lt;br /&gt;
* specify: the tool to generate or to update spec file, based on YAML&lt;br /&gt;
* ini2spectacle: the tool to convert spec-builder .ini to YAML and new spec file&lt;br /&gt;
* spec2spectacle: the tool to convert original spec to YAML and new spec file&lt;br /&gt;
&lt;br /&gt;
== Installation ==&lt;br /&gt;
=== Instruction ===&lt;br /&gt;
Several methods available for spectacle installation:&lt;br /&gt;
&lt;br /&gt;
* Install rpm/deb packages for several supported Linux distributions.&lt;br /&gt;
  From [http://repo.meego.com/tools/repos/ MeeGo Tools Repo], repo urls and install packages can be found for:&lt;br /&gt;
    * MeeGo&lt;br /&gt;
    * Fedora 10,11,12&lt;br /&gt;
    * openSUSE(s)    &lt;br /&gt;
    * xUbuntu 8.10/9.04/9.10/10.04&lt;br /&gt;
    * Debian 5.0            &lt;br /&gt;
&lt;br /&gt;
* Build from the latest source and install it by ``make install``&lt;br /&gt;
  The latest code in git tree can be accessed at:&lt;br /&gt;
  [git://gitorious.org/meego-developer-tools/spectacle.git]&lt;br /&gt;
&lt;br /&gt;
'''Note on Ubuntu installation'''&lt;br /&gt;
From [http://bugs.meego.com/show_bug.cgi?id=6734 this] Edit or create ''/etc/apt/sources.list.d/meego.list'' with sudo&lt;br /&gt;
Add&lt;br /&gt;
 deb http://repo.meego.com/MeeGo/tools/repos/ubuntu/9.10/ /&lt;br /&gt;
&lt;br /&gt;
run the following commands&lt;br /&gt;
 sudo apt-get update&lt;br /&gt;
&lt;br /&gt;
=== Requirements ===&lt;br /&gt;
* python 2.x, above 2.5&lt;br /&gt;
* PyYAML, the python module for YAML parsing&lt;br /&gt;
* cheetah, one popular templating system for python&amp;lt;br&amp;gt;&lt;br /&gt;
    In many linux distributions, the needed package might be &amp;quot;python-cheetah&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
* specify&lt;br /&gt;
    Usage: specify [options] [yaml-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output spec file&lt;br /&gt;
      -s, --skip-scm        Skip to check upstream SCM when specified in YAML&lt;br /&gt;
      -N, --not-download    Do not try to download newer source files&lt;br /&gt;
      -n, --non-interactive&lt;br /&gt;
                              Non interactive running, to use default answers&lt;br /&gt;
       --new=NEWYAML         Create a new yaml from template&lt;br /&gt;
       --newsub=NEWSUB       Append a new sub-package to current yaml&lt;br /&gt;
&lt;br /&gt;
* ini2spectacle&lt;br /&gt;
    Usage: ini2spectacle [options] [ini-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output yaml file&lt;br /&gt;
      -f, --include-files   To store files list in YAML file&lt;br /&gt;
&lt;br /&gt;
* spec2spectacle&lt;br /&gt;
    Usage: spec2spectacle [options] [spec-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output yaml file&lt;br /&gt;
      -r, --replace-macros  To replace self-defined macros in spec file&lt;br /&gt;
      --no-builder-parsing  Do NOT try to parse build/install scripts&lt;br /&gt;
      -f, --include-files   To store files list in YAML file&lt;br /&gt;
&lt;br /&gt;
== Syntax of spectacle YAML ==&lt;br /&gt;
The syntax of YAML can be refered here: &amp;lt;http://www.yaml.org/spec/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Two example spectacle YAML files are placed to examples/ directory in source&lt;br /&gt;
code:&lt;br /&gt;
&lt;br /&gt;
* xfce4-session.yaml, a real world sample with most of the elements&lt;br /&gt;
* general.yaml, a fake spectacle contains all the available elements with comments&lt;br /&gt;
&lt;br /&gt;
All available directives for spectacle are listed as the following:&lt;br /&gt;
&lt;br /&gt;
* Name: **string**&lt;br /&gt;
&lt;br /&gt;
* Summary: **string**&lt;br /&gt;
&lt;br /&gt;
* Version: **string**, version string&lt;br /&gt;
&lt;br /&gt;
* Release: **string**&lt;br /&gt;
&lt;br /&gt;
* Epoch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Group: **string**&lt;br /&gt;
&lt;br /&gt;
* License: **string**&lt;br /&gt;
&lt;br /&gt;
* URL: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* BuildArch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* ExclusiveArch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Prefix: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* LocaleName: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* LocaleOptions: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Description: **text**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Sources: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* SourcePrefix: **string**, *optional*, specify the prefix path in source package&lt;br /&gt;
&lt;br /&gt;
* ExtraSources: **list** of **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* SetupOptions: **string**, *optional*, the options string for %setup&lt;br /&gt;
&lt;br /&gt;
* Patches: **list** of **string**, all patches need to be in 'p1' level&lt;br /&gt;
&lt;br /&gt;
* Requires: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPre: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPreUn: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPost: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPostUn: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* PkgBR: **list** of **string**, packages required in building, or BuildRequires&lt;br /&gt;
&lt;br /&gt;
* PkgConfigBR: **list** of **string**, pkg-config requires in building&lt;br /&gt;
&lt;br /&gt;
* Provides: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Conflicts: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Obsoletes: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* BuildConflicts: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Configure: **string**, *optional*, valid values: **autogen**, **configure**,&lt;br /&gt;
  **reconfigure**, **none**&amp;lt;br&amp;gt;&lt;br /&gt;
  **If not specified, the default value &amp;quot;configure&amp;quot; will be used**&lt;br /&gt;
&lt;br /&gt;
* ConfigOptions: **list**, *optional*, extra options for ``Configure``&lt;br /&gt;
&lt;br /&gt;
* Builder: **string**, *optional*, valid values: **make**, **single-make**,&lt;br /&gt;
  **python**, **perl**, **qmake**, **none**&amp;lt;br&amp;gt;&lt;br /&gt;
  **If not specified, the deault value &amp;quot;make&amp;quot; will be used. If do not want a&lt;br /&gt;
  automatic builder, please use &amp;quot;none&amp;quot;.**&lt;br /&gt;
&lt;br /&gt;
* QMakeOptions: **list**, *optional*, extra options for **qmake** ``Builder``&lt;br /&gt;
&lt;br /&gt;
* Files: **list** of **string**, *optional*, content of ``%files`` for small packages&lt;br /&gt;
&lt;br /&gt;
* FilesInput: **string**, *optional*, extra input source for %files&lt;br /&gt;
&lt;br /&gt;
* NoFiles: **boolean**, *optional*, if to be set as True, means no %files section for this package and it cause no rpm generated&lt;br /&gt;
&lt;br /&gt;
* RunFdupes: **list** of **string**, paths under %{buildroot} to run ``%fdupes`` macro in %install&lt;br /&gt;
&lt;br /&gt;
* RpmLintIgnore: **list**, *optional*, list of skip items for ``rpmlint``&lt;br /&gt;
&lt;br /&gt;
* Check: **boolean**, whether need ``%check`` section in spec&lt;br /&gt;
&lt;br /&gt;
* SupportOtherDistros: **boolean**, whether need to check for other distros (besides MeeGo)&lt;br /&gt;
&lt;br /&gt;
* UseAsNeeded: **boolean**, whether export LD\_AS\_NEEDED=1 environ variable before building&lt;br /&gt;
&lt;br /&gt;
* NoAutoReq: **boolean**, whether add 'AutoReq: 0' to spec&lt;br /&gt;
&lt;br /&gt;
* NoAutoProv: **boolean**, whether add 'AutoProv: 0' to spec&lt;br /&gt;
&lt;br /&gt;
* NoSetup: **boolean**, whether to skip using ``%setup`` in ``%prep``&lt;br /&gt;
&lt;br /&gt;
* NoAutoLocale: **boolean**, whether to use ``%find_lang`` to search locale data when found 'intltool' in PkgBR&lt;br /&gt;
&lt;br /&gt;
* NoDesktop: **boolean**, whether to install the desktop files in package&lt;br /&gt;
&lt;br /&gt;
* UpdateDesktopDB: **boolean**, whether to run 'update-desktop-database' to flush cache when package (un)installation&lt;br /&gt;
&lt;br /&gt;
* AutoDepend: **boolean**, for subpackages only, whether to add Require to main package automatically&lt;br /&gt;
&lt;br /&gt;
* AsWholeName: **boolean**, for subpackages only, whether to use **Name** as the whole package name&lt;br /&gt;
&lt;br /&gt;
* AutoSubPackages: **list** of **string**, mainly for '-devel'&lt;br /&gt;
&lt;br /&gt;
* SubPackages: **list** of **dict**, the **dict** item is the lower level&lt;br /&gt;
directives for sub packages:&lt;br /&gt;
&lt;br /&gt;
    * Name&lt;br /&gt;
    * Summary&lt;br /&gt;
    * Description, *optional*&lt;br /&gt;
    * Group, *optional*&lt;br /&gt;
    * License, *optional*&lt;br /&gt;
    * Requires, *optional*&lt;br /&gt;
    * etc.&lt;br /&gt;
&lt;br /&gt;
**CAUTION**: The following cases of value string have special meaning in YAML syntax:&lt;br /&gt;
&lt;br /&gt;
* string with leading **``%``** charactor&lt;br /&gt;
* string with leading **``*``** charactor&lt;br /&gt;
* string contains **``:``** charactor and one or more spaces/tabs after **``:``**&lt;br /&gt;
* string end with **``:``** charactor&lt;br /&gt;
&lt;br /&gt;
Then these string values need to be quoted by ``'``(single-quote) or ``&amp;quot;``&lt;br /&gt;
(double-quote), and the choice of quote char should not conflict with the value&lt;br /&gt;
string self.&lt;br /&gt;
&lt;br /&gt;
== Namespace support for multi-architecture in several keywords ==&lt;br /&gt;
For the following spectacle YAML keywords:&lt;br /&gt;
&lt;br /&gt;
* Requires&lt;br /&gt;
* PkgBR&lt;br /&gt;
* PkgConfigBR&lt;br /&gt;
* Patches&lt;br /&gt;
* ConfigOptions&lt;br /&gt;
* QMakeOptions&lt;br /&gt;
&lt;br /&gt;
If one of the items need to be architecture specified, we can add arch prefix to&lt;br /&gt;
it. The supported prefix and the corresponding architectures as the followings:&lt;br /&gt;
&lt;br /&gt;
* ``ix86:`` -   x86 platform&lt;br /&gt;
* ``arm:``  -   arm platform&lt;br /&gt;
&lt;br /&gt;
Here's some samples:&lt;br /&gt;
&lt;br /&gt;
    Requires:&lt;br /&gt;
        - arm:pkg-need-in-arm-image&lt;br /&gt;
        - ix86:pkg-need-in-x86-image&lt;br /&gt;
        - normal-pkg&lt;br /&gt;
    ConfigOptions:&lt;br /&gt;
        - arm:--arm-specific-opt&lt;br /&gt;
        - ix86:--ix86-specific-opt&lt;br /&gt;
        - --common-opt&lt;br /&gt;
&lt;br /&gt;
== Customizations in spec ==&lt;br /&gt;
Generated spec files by specify will have many placeholders for customizations,&lt;br /&gt;
such as:&lt;br /&gt;
&lt;br /&gt;
    # &amp;gt;&amp;gt; build pre&lt;br /&gt;
    # &amp;lt;&amp;lt; build pre&lt;br /&gt;
&lt;br /&gt;
You can add any custom code between the markers, next time when you run&lt;br /&gt;
``specify``, the text between the markers will be kept as is, all other sections&lt;br /&gt;
relying on the meta data from the YAML file will be changed depending on the&lt;br /&gt;
values in the YAML file.&lt;br /&gt;
&lt;br /&gt;
The following placeholders in spec can be customized:&lt;br /&gt;
&lt;br /&gt;
* Private Macros, used in this package's spec&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; macros&lt;br /&gt;
        # &amp;lt;&amp;lt; macros&lt;br /&gt;
&lt;br /&gt;
* Extra setup scripts in the last of ``%prep``&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; setup&lt;br /&gt;
        # &amp;lt;&amp;lt; setup&lt;br /&gt;
&lt;br /&gt;
* Pre-Build, scripts before package building&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; build pre&lt;br /&gt;
        # &amp;lt;&amp;lt; build pre&lt;br /&gt;
&lt;br /&gt;
* Post-Build, scripts after package building&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; build post&lt;br /&gt;
        # &amp;lt;&amp;lt; build post&lt;br /&gt;
&lt;br /&gt;
* Pre-Install, scripts before package installation&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; install pre&lt;br /&gt;
        # &amp;lt;&amp;lt; install pre&lt;br /&gt;
&lt;br /&gt;
* Post-Install, scripts after package installation&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; install post&lt;br /&gt;
        # &amp;lt;&amp;lt; install post&lt;br /&gt;
&lt;br /&gt;
* Files, files list in packaged rpm&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; files [sub-package]&lt;br /&gt;
        # &amp;lt;&amp;lt; files [sub-package]&lt;br /&gt;
NOTE**: &amp;quot;sub-packge&amp;quot; stands for the name of sub-package, and it is optional. If no sub-package name specified, it means the files of **main** package.&lt;br /&gt;
NOTE**: If the file list is simple enough, you can use YAML *Files* keyword instead to record it.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %check section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; check&lt;br /&gt;
        # &amp;lt;&amp;lt; check&lt;br /&gt;
NOTE**: Only if YAML boolean *Check* is specifed as ``yes``, %check with placeholder lines will be generated in .spec.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %pre section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; pre&lt;br /&gt;
        # &amp;lt;&amp;lt; pre&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %preun section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; preun&lt;br /&gt;
        # &amp;lt;&amp;lt; preun&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %post section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; post&lt;br /&gt;
        # &amp;lt;&amp;lt; post&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %postun section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; postun&lt;br /&gt;
        # &amp;lt;&amp;lt; postun&lt;br /&gt;
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.&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Spectacle</id>
		<title>Spectacle</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Spectacle"/>
				<updated>2010-11-25T04:26:43Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* Syntax of spectacle YAML */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Spectacle is the toolset for packaging maintenance of MeeGo, including the tool&lt;br /&gt;
to generate spec files from metadata file in YAML format, and tools to convert  &lt;br /&gt;
spec files or spec-builder's ini files to YAML format.                          &lt;br /&gt;
&lt;br /&gt;
For spectacle managed packages, all generic packaging information will be stored&lt;br /&gt;
in the YAML file, and it also allows maintaining customizations in the spec file&lt;br /&gt;
directly with special enclosure tags.                                           &lt;br /&gt;
&lt;br /&gt;
Three separated tools will be installed:&lt;br /&gt;
&lt;br /&gt;
* specify: the tool to generate or to update spec file, based on YAML&lt;br /&gt;
* ini2spectacle: the tool to convert spec-builder .ini to YAML and new spec file&lt;br /&gt;
* spec2spectacle: the tool to convert original spec to YAML and new spec file&lt;br /&gt;
&lt;br /&gt;
== Installation ==&lt;br /&gt;
=== Instruction ===&lt;br /&gt;
Several methods available for spectacle installation:&lt;br /&gt;
&lt;br /&gt;
* Install rpm/deb packages for several supported Linux distributions.&lt;br /&gt;
  From [http://repo.meego.com/tools/repos/ MeeGo Tools Repo], repo urls and install packages can be found for:&lt;br /&gt;
    * MeeGo&lt;br /&gt;
    * Fedora 10,11,12&lt;br /&gt;
    * openSUSE(s)    &lt;br /&gt;
    * xUbuntu 8.10/9.04/9.10/10.04&lt;br /&gt;
    * Debian 5.0            &lt;br /&gt;
&lt;br /&gt;
* Build from the latest source and install it by ``make install``&lt;br /&gt;
  The latest code in git tree can be accessed at:&lt;br /&gt;
  [git://gitorious.org/meego-developer-tools/spectacle.git]&lt;br /&gt;
&lt;br /&gt;
'''Note on Ubuntu installation'''&lt;br /&gt;
From [http://bugs.meego.com/show_bug.cgi?id=6734 this] Edit or create ''/etc/apt/sources.list.d/meego.list'' with sudo&lt;br /&gt;
Add&lt;br /&gt;
 deb http://repo.meego.com/MeeGo/tools/repos/ubuntu/9.10/ /&lt;br /&gt;
&lt;br /&gt;
run the following commands&lt;br /&gt;
 sudo apt-get update&lt;br /&gt;
&lt;br /&gt;
=== Requirements ===&lt;br /&gt;
* python 2.x, above 2.5&lt;br /&gt;
* PyYAML, the python module for YAML parsing&lt;br /&gt;
* cheetah, one popular templating system for python&amp;lt;br&amp;gt;&lt;br /&gt;
    In many linux distributions, the needed package might be &amp;quot;python-cheetah&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
* specify&lt;br /&gt;
    Usage: specify [options] [yaml-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output spec file&lt;br /&gt;
      -s, --skip-scm        Skip to check upstream SCM when specified in YAML&lt;br /&gt;
      -N, --not-download    Do not try to download newer source files&lt;br /&gt;
      -n, --non-interactive&lt;br /&gt;
                              Non interactive running, to use default answers&lt;br /&gt;
       --new=NEWYAML         Create a new yaml from template&lt;br /&gt;
       --newsub=NEWSUB       Append a new sub-package to current yaml&lt;br /&gt;
&lt;br /&gt;
* ini2spectacle&lt;br /&gt;
    Usage: ini2spectacle [options] [ini-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output yaml file&lt;br /&gt;
      -f, --include-files   To store files list in YAML file&lt;br /&gt;
&lt;br /&gt;
* spec2spectacle&lt;br /&gt;
    Usage: spec2spectacle [options] [spec-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output yaml file&lt;br /&gt;
      -r, --replace-macros  To replace self-defined macros in spec file&lt;br /&gt;
      --no-builder-parsing  Do NOT try to parse build/install scripts&lt;br /&gt;
      -f, --include-files   To store files list in YAML file&lt;br /&gt;
&lt;br /&gt;
== Syntax of spectacle YAML ==&lt;br /&gt;
The syntax of YAML can be refered here: &amp;lt;http://www.yaml.org/spec/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Two example spectacle YAML files are placed to examples/ directory in source&lt;br /&gt;
code:&lt;br /&gt;
&lt;br /&gt;
* xfce4-session.yaml, a real world sample with most of the elements&lt;br /&gt;
* general.yaml, a fake spectacle contains all the available elements with comments&lt;br /&gt;
&lt;br /&gt;
All available directives for spectacle are listed as the following:&lt;br /&gt;
&lt;br /&gt;
* Name: **string**&lt;br /&gt;
&lt;br /&gt;
* Summary: **string**&lt;br /&gt;
&lt;br /&gt;
* Version: **string**, version string&lt;br /&gt;
&lt;br /&gt;
* Release: **string**&lt;br /&gt;
&lt;br /&gt;
* Epoch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Group: **string**&lt;br /&gt;
&lt;br /&gt;
* License: **string**&lt;br /&gt;
&lt;br /&gt;
* URL: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* BuildArch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* ExclusiveArch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Prefix: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* LocaleName: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* LocaleOptions: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Description: **text**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Sources: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* SourcePrefix: **string**, *optional*, specify the prefix path in source package&lt;br /&gt;
&lt;br /&gt;
* ExtraSources: **list** of **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* SetupOptions: **string**, *optional*, the options string for %setup&lt;br /&gt;
&lt;br /&gt;
* Patches: **list** of **string**, all patches need to be in 'p1' level&lt;br /&gt;
&lt;br /&gt;
* Requires: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPre: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPreUn: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPost: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPostUn: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* PkgBR: **list** of **string**, packages required in building, or BuildRequires&lt;br /&gt;
&lt;br /&gt;
* PkgConfigBR: **list** of **string**, pkg-config requires in building&lt;br /&gt;
&lt;br /&gt;
* Provides: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Conflicts: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Obsoletes: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* BuildConflicts: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Configure: **string**, *optional*, valid values: **autogen**, **configure**,&lt;br /&gt;
  **reconfigure**, **none**&amp;lt;br&amp;gt;&lt;br /&gt;
  **If not specified, the default value &amp;quot;configure&amp;quot; will be used**&lt;br /&gt;
&lt;br /&gt;
* ConfigOptions: **list**, *optional*, extra options for ``Configure``&lt;br /&gt;
&lt;br /&gt;
* Builder: **string**, *optional*, valid values: **make**, **single-make**,&lt;br /&gt;
  **python**, **perl**, **qmake**, **none**&amp;lt;br&amp;gt;&lt;br /&gt;
  **If not specified, the deault value &amp;quot;make&amp;quot; will be used. If do not want a&lt;br /&gt;
  automatic builder, please use &amp;quot;none&amp;quot;.**&lt;br /&gt;
&lt;br /&gt;
* QMakeOptions: **list**, *optional*, extra options for **qmake** ``Builder``&lt;br /&gt;
&lt;br /&gt;
* Files: **list** of **string**, *optional*, content of ``%files`` for small packages&lt;br /&gt;
&lt;br /&gt;
* FilesInput: **string**, *optional*, extra input source for %files&lt;br /&gt;
&lt;br /&gt;
* NoFiles: **boolean**, *optional*, if to be set as True, means no %files section for this package and it cause no rpm generated&lt;br /&gt;
&lt;br /&gt;
* RunFdupes: **list** of **string**, paths under %{buildroot} to run ``%fdupes`` macro in %install&lt;br /&gt;
&lt;br /&gt;
* RpmLintIgnore: **list**, *optional*, list of skip items for ``rpmlint``&lt;br /&gt;
&lt;br /&gt;
* Check: **boolean**, whether need ``%check`` section in spec&lt;br /&gt;
&lt;br /&gt;
* SupportOtherDistros: **boolean**, whether need to check for other distros (besides MeeGo)&lt;br /&gt;
&lt;br /&gt;
* UseAsNeeded: **boolean**, whether export LD\_AS\_NEEDED=1 environ variable before building&lt;br /&gt;
&lt;br /&gt;
* NoAutoReq: **boolean**, whether add 'AutoReq: 0' to spec&lt;br /&gt;
&lt;br /&gt;
* NoAutoProv: **boolean**, whether add 'AutoProv: 0' to spec&lt;br /&gt;
&lt;br /&gt;
* NoSetup: **boolean**, whether to skip using ``%setup`` in ``%prep``&lt;br /&gt;
&lt;br /&gt;
* NoAutoLocale: **boolean**, whether to use ``%find_lang`` to search locale data when found 'intltool' in PkgBR&lt;br /&gt;
&lt;br /&gt;
* NoDesktop: **boolean**, whether to install the desktop files in package&lt;br /&gt;
&lt;br /&gt;
* UpdateDesktopDB: **boolean**, whether to run 'update-desktop-database' to flush cache when package (un)installation&lt;br /&gt;
&lt;br /&gt;
* AutoDepend: **boolean**, for subpackages only, whether to add Require to main package automatically&lt;br /&gt;
&lt;br /&gt;
* AsWholeName: **boolean**, for subpackages only, whether to use **Name** as the whole package name&lt;br /&gt;
&lt;br /&gt;
* AutoSubPackages: **list** of **string**, mainly for '-devel'&lt;br /&gt;
&lt;br /&gt;
* SubPackages: **list** of **dict**, the **dict** item is the lower level&lt;br /&gt;
directives for sub packages:&lt;br /&gt;
&lt;br /&gt;
    * Name&lt;br /&gt;
    * Summary&lt;br /&gt;
    * Description, *optional*&lt;br /&gt;
    * Group, *optional*&lt;br /&gt;
    * License, *optional*&lt;br /&gt;
    * Requires, *optional*&lt;br /&gt;
    * etc.&lt;br /&gt;
&lt;br /&gt;
**CAUTION**: The following cases of value string have special meaning in YAML syntax:&lt;br /&gt;
&lt;br /&gt;
* string with leading **``%``** charactor&lt;br /&gt;
* string with leading **``*``** charactor&lt;br /&gt;
* string contains **``:``** charactor and one or more spaces/tabs after **``:``**&lt;br /&gt;
* string end with **``:``** charactor&lt;br /&gt;
&lt;br /&gt;
Then these string values need to be quoted by ``'``(single-quote) or ``&amp;quot;``&lt;br /&gt;
(double-quote), and the choice of quote char should not conflict with the value&lt;br /&gt;
string self.&lt;br /&gt;
&lt;br /&gt;
== Namespace support for multi-architecture in several keywords ==&lt;br /&gt;
For the following spectacle YAML keywords:&lt;br /&gt;
&lt;br /&gt;
* Requires&lt;br /&gt;
* PkgBR&lt;br /&gt;
* PkgConfigBR&lt;br /&gt;
* Patches&lt;br /&gt;
* ConfigOptions&lt;br /&gt;
&lt;br /&gt;
If one of the items need to be architecture specified, we can add arch prefix to&lt;br /&gt;
it. The supported prefix and the corresponding architectures as the followings:&lt;br /&gt;
&lt;br /&gt;
* ``ix86:`` -   x86 platform&lt;br /&gt;
* ``arm:``  -   arm platform&lt;br /&gt;
&lt;br /&gt;
Here's some samples:&lt;br /&gt;
&lt;br /&gt;
    Requires:&lt;br /&gt;
        - arm:pkg-need-in-arm-image&lt;br /&gt;
        - ix86:pkg-need-in-x86-image&lt;br /&gt;
        - normal-pkg&lt;br /&gt;
    ConfigOptions:&lt;br /&gt;
        - arm:--arm-specific-opt&lt;br /&gt;
        - ix86:--ix86-specific-opt&lt;br /&gt;
        - --common-opt&lt;br /&gt;
&lt;br /&gt;
== Customizations in spec ==&lt;br /&gt;
Generated spec files by specify will have many placeholders for customizations,&lt;br /&gt;
such as:&lt;br /&gt;
&lt;br /&gt;
    # &amp;gt;&amp;gt; build pre&lt;br /&gt;
    # &amp;lt;&amp;lt; build pre&lt;br /&gt;
&lt;br /&gt;
You can add any custom code between the markers, next time when you run&lt;br /&gt;
``specify``, the text between the markers will be kept as is, all other sections&lt;br /&gt;
relying on the meta data from the YAML file will be changed depending on the&lt;br /&gt;
values in the YAML file.&lt;br /&gt;
&lt;br /&gt;
The following placeholders in spec can be customized:&lt;br /&gt;
&lt;br /&gt;
* Private Macros, used in this package's spec&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; macros&lt;br /&gt;
        # &amp;lt;&amp;lt; macros&lt;br /&gt;
&lt;br /&gt;
* Extra setup scripts in the last of ``%prep``&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; setup&lt;br /&gt;
        # &amp;lt;&amp;lt; setup&lt;br /&gt;
&lt;br /&gt;
* Pre-Build, scripts before package building&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; build pre&lt;br /&gt;
        # &amp;lt;&amp;lt; build pre&lt;br /&gt;
&lt;br /&gt;
* Post-Build, scripts after package building&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; build post&lt;br /&gt;
        # &amp;lt;&amp;lt; build post&lt;br /&gt;
&lt;br /&gt;
* Pre-Install, scripts before package installation&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; install pre&lt;br /&gt;
        # &amp;lt;&amp;lt; install pre&lt;br /&gt;
&lt;br /&gt;
* Post-Install, scripts after package installation&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; install post&lt;br /&gt;
        # &amp;lt;&amp;lt; install post&lt;br /&gt;
&lt;br /&gt;
* Files, files list in packaged rpm&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; files [sub-package]&lt;br /&gt;
        # &amp;lt;&amp;lt; files [sub-package]&lt;br /&gt;
NOTE**: &amp;quot;sub-packge&amp;quot; stands for the name of sub-package, and it is optional. If no sub-package name specified, it means the files of **main** package.&lt;br /&gt;
NOTE**: If the file list is simple enough, you can use YAML *Files* keyword instead to record it.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %check section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; check&lt;br /&gt;
        # &amp;lt;&amp;lt; check&lt;br /&gt;
NOTE**: Only if YAML boolean *Check* is specifed as ``yes``, %check with placeholder lines will be generated in .spec.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %pre section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; pre&lt;br /&gt;
        # &amp;lt;&amp;lt; pre&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %preun section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; preun&lt;br /&gt;
        # &amp;lt;&amp;lt; preun&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %post section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; post&lt;br /&gt;
        # &amp;lt;&amp;lt; post&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %postun section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; postun&lt;br /&gt;
        # &amp;lt;&amp;lt; postun&lt;br /&gt;
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.&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Spectacle</id>
		<title>Spectacle</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Spectacle"/>
				<updated>2010-11-25T04:20:37Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* Usage */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Spectacle is the toolset for packaging maintenance of MeeGo, including the tool&lt;br /&gt;
to generate spec files from metadata file in YAML format, and tools to convert  &lt;br /&gt;
spec files or spec-builder's ini files to YAML format.                          &lt;br /&gt;
&lt;br /&gt;
For spectacle managed packages, all generic packaging information will be stored&lt;br /&gt;
in the YAML file, and it also allows maintaining customizations in the spec file&lt;br /&gt;
directly with special enclosure tags.                                           &lt;br /&gt;
&lt;br /&gt;
Three separated tools will be installed:&lt;br /&gt;
&lt;br /&gt;
* specify: the tool to generate or to update spec file, based on YAML&lt;br /&gt;
* ini2spectacle: the tool to convert spec-builder .ini to YAML and new spec file&lt;br /&gt;
* spec2spectacle: the tool to convert original spec to YAML and new spec file&lt;br /&gt;
&lt;br /&gt;
== Installation ==&lt;br /&gt;
=== Instruction ===&lt;br /&gt;
Several methods available for spectacle installation:&lt;br /&gt;
&lt;br /&gt;
* Install rpm/deb packages for several supported Linux distributions.&lt;br /&gt;
  From [http://repo.meego.com/tools/repos/ MeeGo Tools Repo], repo urls and install packages can be found for:&lt;br /&gt;
    * MeeGo&lt;br /&gt;
    * Fedora 10,11,12&lt;br /&gt;
    * openSUSE(s)    &lt;br /&gt;
    * xUbuntu 8.10/9.04/9.10/10.04&lt;br /&gt;
    * Debian 5.0            &lt;br /&gt;
&lt;br /&gt;
* Build from the latest source and install it by ``make install``&lt;br /&gt;
  The latest code in git tree can be accessed at:&lt;br /&gt;
  [git://gitorious.org/meego-developer-tools/spectacle.git]&lt;br /&gt;
&lt;br /&gt;
'''Note on Ubuntu installation'''&lt;br /&gt;
From [http://bugs.meego.com/show_bug.cgi?id=6734 this] Edit or create ''/etc/apt/sources.list.d/meego.list'' with sudo&lt;br /&gt;
Add&lt;br /&gt;
 deb http://repo.meego.com/MeeGo/tools/repos/ubuntu/9.10/ /&lt;br /&gt;
&lt;br /&gt;
run the following commands&lt;br /&gt;
 sudo apt-get update&lt;br /&gt;
&lt;br /&gt;
=== Requirements ===&lt;br /&gt;
* python 2.x, above 2.5&lt;br /&gt;
* PyYAML, the python module for YAML parsing&lt;br /&gt;
* cheetah, one popular templating system for python&amp;lt;br&amp;gt;&lt;br /&gt;
    In many linux distributions, the needed package might be &amp;quot;python-cheetah&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
* specify&lt;br /&gt;
    Usage: specify [options] [yaml-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output spec file&lt;br /&gt;
      -s, --skip-scm        Skip to check upstream SCM when specified in YAML&lt;br /&gt;
      -N, --not-download    Do not try to download newer source files&lt;br /&gt;
      -n, --non-interactive&lt;br /&gt;
                              Non interactive running, to use default answers&lt;br /&gt;
       --new=NEWYAML         Create a new yaml from template&lt;br /&gt;
       --newsub=NEWSUB       Append a new sub-package to current yaml&lt;br /&gt;
&lt;br /&gt;
* ini2spectacle&lt;br /&gt;
    Usage: ini2spectacle [options] [ini-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output yaml file&lt;br /&gt;
      -f, --include-files   To store files list in YAML file&lt;br /&gt;
&lt;br /&gt;
* spec2spectacle&lt;br /&gt;
    Usage: spec2spectacle [options] [spec-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output yaml file&lt;br /&gt;
      -r, --replace-macros  To replace self-defined macros in spec file&lt;br /&gt;
      --no-builder-parsing  Do NOT try to parse build/install scripts&lt;br /&gt;
      -f, --include-files   To store files list in YAML file&lt;br /&gt;
&lt;br /&gt;
== Syntax of spectacle YAML ==&lt;br /&gt;
The syntax of YAML can be refered here: &amp;lt;http://www.yaml.org/spec/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Two example spectacle YAML files are placed to examples/ directory in source&lt;br /&gt;
code:&lt;br /&gt;
&lt;br /&gt;
* xfce4-session.yaml, a real world sample with most of the elements&lt;br /&gt;
* general.yaml, a fake spectacle contains all the available elements with comments&lt;br /&gt;
&lt;br /&gt;
All available directives for spectacle are listed as the following:&lt;br /&gt;
&lt;br /&gt;
* Name: **string**&lt;br /&gt;
&lt;br /&gt;
* Summary: **string**&lt;br /&gt;
&lt;br /&gt;
* Version: **string**, version string (not version NUMBER)&lt;br /&gt;
&lt;br /&gt;
* Release: **string**&lt;br /&gt;
&lt;br /&gt;
* Epoch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Group: **string**&lt;br /&gt;
&lt;br /&gt;
* License: **string**&lt;br /&gt;
&lt;br /&gt;
* URL: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* BuildArch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* ExclusiveArch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* LocaleName: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* LocaleOptions: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Description: **text**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Sources: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* SourcePrefix: **string**, *optional*, specify the prefix path in source package&lt;br /&gt;
&lt;br /&gt;
* ExtraSources: **list** of **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* SetupOptions: **string**, *optional*, the options string for %setup&lt;br /&gt;
&lt;br /&gt;
* ExtraInstall: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Patches: **list** of **string**, all patches need to be in 'p1' level&lt;br /&gt;
&lt;br /&gt;
* Requires: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPre: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPreUn: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPost: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPostUn: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* PkgBR: **list** of **string**, packages required by build, or BuildRequires&lt;br /&gt;
&lt;br /&gt;
* PkgConfigBR: **list** of **string**, pkg-config requires by build&lt;br /&gt;
&lt;br /&gt;
* Provides: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Conflicts: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Obsoletes: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Configure: **string**, *optional*, valid values: **autogen**, **configure**, **reconfigure**, **none**&amp;lt;br&amp;gt;&lt;br /&gt;
**If not specified, the default value ``configure`` will be used**&lt;br /&gt;
&lt;br /&gt;
* Builder: **string**, *optional*, valid values: **make**, **single-make**, **python**, **perl**, **none**&amp;lt;br&amp;gt;&lt;br /&gt;
**If not specified, the default value ``make`` will be used. If do not want an automatic builder, please use ``none``.**&lt;br /&gt;
&lt;br /&gt;
* Files: **list** of **string**, *optional*, content of ``%files`` for small packages&lt;br /&gt;
&lt;br /&gt;
* FilesInput: **string**, *optional*, extra input source for %files&lt;br /&gt;
&lt;br /&gt;
* NoFiles: **boolean**, *optional*, if to be set as True, means no %files section for this package and it cause no rpm generated&lt;br /&gt;
&lt;br /&gt;
* RunFdupes: **string**, parameters of ``fdupes`` in %install&lt;br /&gt;
&lt;br /&gt;
* RpmLintIgnore: **list**, *optional*, list of skip items for ``rpmlint``&lt;br /&gt;
&lt;br /&gt;
* Check: **boolean**, whether need ``%check`` section in spec&lt;br /&gt;
&lt;br /&gt;
* SupportOtherDistros: **boolean**, whether need to check for other distros (besides MeeGo)&lt;br /&gt;
&lt;br /&gt;
* UseAsNeeded: **boolean**, whether export LD_AS_NEEDED=1 env when building&lt;br /&gt;
&lt;br /&gt;
* NoAutoReq: **boolean**, whether add 'AutoReq: 0' to spec&lt;br /&gt;
&lt;br /&gt;
* NoAutoProv: **boolean**, whether add 'AutoProv: 0' to spec&lt;br /&gt;
&lt;br /&gt;
* NoSetup: **boolean**, whether to skip using ``%setup`` in ``%prep``&lt;br /&gt;
&lt;br /&gt;
* NoAutoLocale: **boolean**, whether to use ``%find_lang`` to search locale data when found 'inittool' in PkgBR&lt;br /&gt;
&lt;br /&gt;
* NoDesktop: **boolean**, whether to install the desktop files in package&lt;br /&gt;
&lt;br /&gt;
* UpdateDesktopDB: **boolean**, whether to run 'update-desktop-database' to flush cache when package (un)installation&lt;br /&gt;
&lt;br /&gt;
* AutoDepend: **boolean**, for subpackages only, whether to add Require to main package automatically&lt;br /&gt;
&lt;br /&gt;
* AsWholeName: **boolean**, for subpackages only, whether to use **Name** as the whole package name&lt;br /&gt;
&lt;br /&gt;
* AutoSubPackages: **list** of **string**, mainly for '-devel'&lt;br /&gt;
&lt;br /&gt;
* SubPackages: **list** of **dict**, the **dict** item is the lower level directives for sub packages:&lt;br /&gt;
    * Name&lt;br /&gt;
    * Summary&lt;br /&gt;
    * Description, *optional*&lt;br /&gt;
    * Group, *optional*&lt;br /&gt;
    * Requires, *optional*&lt;br /&gt;
    * FilesInput, *optional*&lt;br /&gt;
    * etc.&lt;br /&gt;
&lt;br /&gt;
CAUTION: The following cases of value string have special meaning in YAML syntax:&lt;br /&gt;
    * string with leading **``%``** charactor&lt;br /&gt;
    * string with leading **``*``** charactor&lt;br /&gt;
    * string contains **``:``** charactor and one or more spaces/tabs after **``:``**&lt;br /&gt;
Then these string values need to be quoted by ``'``(single-quote) or ``&amp;quot;`` (double-quote), and the choice of quote char should not conflict with the value string self.**&lt;br /&gt;
&lt;br /&gt;
== Namespace support for multi-architecture in several keywords ==&lt;br /&gt;
For the following spectacle YAML keywords:&lt;br /&gt;
&lt;br /&gt;
* Requires&lt;br /&gt;
* PkgBR&lt;br /&gt;
* PkgConfigBR&lt;br /&gt;
* Patches&lt;br /&gt;
* ConfigOptions&lt;br /&gt;
&lt;br /&gt;
If one of the items need to be architecture specified, we can add arch prefix to&lt;br /&gt;
it. The supported prefix and the corresponding architectures as the followings:&lt;br /&gt;
&lt;br /&gt;
* ``ix86:`` -   x86 platform&lt;br /&gt;
* ``arm:``  -   arm platform&lt;br /&gt;
&lt;br /&gt;
Here's some samples:&lt;br /&gt;
&lt;br /&gt;
    Requires:&lt;br /&gt;
        - arm:pkg-need-in-arm-image&lt;br /&gt;
        - ix86:pkg-need-in-x86-image&lt;br /&gt;
        - normal-pkg&lt;br /&gt;
    ConfigOptions:&lt;br /&gt;
        - arm:--arm-specific-opt&lt;br /&gt;
        - ix86:--ix86-specific-opt&lt;br /&gt;
        - --common-opt&lt;br /&gt;
&lt;br /&gt;
== Customizations in spec ==&lt;br /&gt;
Generated spec files by specify will have many placeholders for customizations,&lt;br /&gt;
such as:&lt;br /&gt;
&lt;br /&gt;
    # &amp;gt;&amp;gt; build pre&lt;br /&gt;
    # &amp;lt;&amp;lt; build pre&lt;br /&gt;
&lt;br /&gt;
You can add any custom code between the markers, next time when you run&lt;br /&gt;
``specify``, the text between the markers will be kept as is, all other sections&lt;br /&gt;
relying on the meta data from the YAML file will be changed depending on the&lt;br /&gt;
values in the YAML file.&lt;br /&gt;
&lt;br /&gt;
The following placeholders in spec can be customized:&lt;br /&gt;
&lt;br /&gt;
* Private Macros, used in this package's spec&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; macros&lt;br /&gt;
        # &amp;lt;&amp;lt; macros&lt;br /&gt;
&lt;br /&gt;
* Extra setup scripts in the last of ``%prep``&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; setup&lt;br /&gt;
        # &amp;lt;&amp;lt; setup&lt;br /&gt;
&lt;br /&gt;
* Pre-Build, scripts before package building&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; build pre&lt;br /&gt;
        # &amp;lt;&amp;lt; build pre&lt;br /&gt;
&lt;br /&gt;
* Post-Build, scripts after package building&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; build post&lt;br /&gt;
        # &amp;lt;&amp;lt; build post&lt;br /&gt;
&lt;br /&gt;
* Pre-Install, scripts before package installation&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; install pre&lt;br /&gt;
        # &amp;lt;&amp;lt; install pre&lt;br /&gt;
&lt;br /&gt;
* Post-Install, scripts after package installation&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; install post&lt;br /&gt;
        # &amp;lt;&amp;lt; install post&lt;br /&gt;
&lt;br /&gt;
* Files, files list in packaged rpm&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; files [sub-package]&lt;br /&gt;
        # &amp;lt;&amp;lt; files [sub-package]&lt;br /&gt;
NOTE**: &amp;quot;sub-packge&amp;quot; stands for the name of sub-package, and it is optional. If no sub-package name specified, it means the files of **main** package.&lt;br /&gt;
NOTE**: If the file list is simple enough, you can use YAML *Files* keyword instead to record it.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %check section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; check&lt;br /&gt;
        # &amp;lt;&amp;lt; check&lt;br /&gt;
NOTE**: Only if YAML boolean *Check* is specifed as ``yes``, %check with placeholder lines will be generated in .spec.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %pre section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; pre&lt;br /&gt;
        # &amp;lt;&amp;lt; pre&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %preun section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; preun&lt;br /&gt;
        # &amp;lt;&amp;lt; preun&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %post section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; post&lt;br /&gt;
        # &amp;lt;&amp;lt; post&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %postun section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; postun&lt;br /&gt;
        # &amp;lt;&amp;lt; postun&lt;br /&gt;
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.&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Spectacle</id>
		<title>Spectacle</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Spectacle"/>
				<updated>2010-11-25T04:18:57Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* Requirements */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Spectacle is the toolset for packaging maintenance of MeeGo, including the tool&lt;br /&gt;
to generate spec files from metadata file in YAML format, and tools to convert  &lt;br /&gt;
spec files or spec-builder's ini files to YAML format.                          &lt;br /&gt;
&lt;br /&gt;
For spectacle managed packages, all generic packaging information will be stored&lt;br /&gt;
in the YAML file, and it also allows maintaining customizations in the spec file&lt;br /&gt;
directly with special enclosure tags.                                           &lt;br /&gt;
&lt;br /&gt;
Three separated tools will be installed:&lt;br /&gt;
&lt;br /&gt;
* specify: the tool to generate or to update spec file, based on YAML&lt;br /&gt;
* ini2spectacle: the tool to convert spec-builder .ini to YAML and new spec file&lt;br /&gt;
* spec2spectacle: the tool to convert original spec to YAML and new spec file&lt;br /&gt;
&lt;br /&gt;
== Installation ==&lt;br /&gt;
=== Instruction ===&lt;br /&gt;
Several methods available for spectacle installation:&lt;br /&gt;
&lt;br /&gt;
* Install rpm/deb packages for several supported Linux distributions.&lt;br /&gt;
  From [http://repo.meego.com/tools/repos/ MeeGo Tools Repo], repo urls and install packages can be found for:&lt;br /&gt;
    * MeeGo&lt;br /&gt;
    * Fedora 10,11,12&lt;br /&gt;
    * openSUSE(s)    &lt;br /&gt;
    * xUbuntu 8.10/9.04/9.10/10.04&lt;br /&gt;
    * Debian 5.0            &lt;br /&gt;
&lt;br /&gt;
* Build from the latest source and install it by ``make install``&lt;br /&gt;
  The latest code in git tree can be accessed at:&lt;br /&gt;
  [git://gitorious.org/meego-developer-tools/spectacle.git]&lt;br /&gt;
&lt;br /&gt;
'''Note on Ubuntu installation'''&lt;br /&gt;
From [http://bugs.meego.com/show_bug.cgi?id=6734 this] Edit or create ''/etc/apt/sources.list.d/meego.list'' with sudo&lt;br /&gt;
Add&lt;br /&gt;
 deb http://repo.meego.com/MeeGo/tools/repos/ubuntu/9.10/ /&lt;br /&gt;
&lt;br /&gt;
run the following commands&lt;br /&gt;
 sudo apt-get update&lt;br /&gt;
&lt;br /&gt;
=== Requirements ===&lt;br /&gt;
* python 2.x, above 2.5&lt;br /&gt;
* PyYAML, the python module for YAML parsing&lt;br /&gt;
* cheetah, one popular templating system for python&amp;lt;br&amp;gt;&lt;br /&gt;
    In many linux distributions, the needed package might be &amp;quot;python-cheetah&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
* specify&lt;br /&gt;
    Usage: specify [options] [yaml-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output spec file&lt;br /&gt;
      -s, --skip-scm        Skip to check upstream SCM when specified in YAML&lt;br /&gt;
      -N, --not-download    Do not try to download newer source files&lt;br /&gt;
&lt;br /&gt;
* ini2spectacle&lt;br /&gt;
    Usage: ini2spectacle [options] [ini-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output yaml file&lt;br /&gt;
      -f, --include-files   To store files list in YAML file&lt;br /&gt;
&lt;br /&gt;
* spec2spectacle&lt;br /&gt;
    Usage: spec2spectacle [options] [spec-path]&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -o OUTFILE_PATH, --output=OUTFILE_PATH&lt;br /&gt;
                            Path of output yaml file&lt;br /&gt;
      -r, --replace-macros  To replace self-defined macros in spec file&lt;br /&gt;
      --no-builder-parsing  Do NOT try to parse build/install scripts&lt;br /&gt;
      -f, --include-files   To store files list in YAML file&lt;br /&gt;
&lt;br /&gt;
== Syntax of spectacle YAML ==&lt;br /&gt;
The syntax of YAML can be refered here: &amp;lt;http://www.yaml.org/spec/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Two example spectacle YAML files are placed to examples/ directory in source&lt;br /&gt;
code:&lt;br /&gt;
&lt;br /&gt;
* xfce4-session.yaml, a real world sample with most of the elements&lt;br /&gt;
* general.yaml, a fake spectacle contains all the available elements with comments&lt;br /&gt;
&lt;br /&gt;
All available directives for spectacle are listed as the following:&lt;br /&gt;
&lt;br /&gt;
* Name: **string**&lt;br /&gt;
&lt;br /&gt;
* Summary: **string**&lt;br /&gt;
&lt;br /&gt;
* Version: **string**, version string (not version NUMBER)&lt;br /&gt;
&lt;br /&gt;
* Release: **string**&lt;br /&gt;
&lt;br /&gt;
* Epoch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Group: **string**&lt;br /&gt;
&lt;br /&gt;
* License: **string**&lt;br /&gt;
&lt;br /&gt;
* URL: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* BuildArch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* ExclusiveArch: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* LocaleName: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* LocaleOptions: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Description: **text**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Sources: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* SourcePrefix: **string**, *optional*, specify the prefix path in source package&lt;br /&gt;
&lt;br /&gt;
* ExtraSources: **list** of **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* SetupOptions: **string**, *optional*, the options string for %setup&lt;br /&gt;
&lt;br /&gt;
* ExtraInstall: **string**, *optional*&lt;br /&gt;
&lt;br /&gt;
* Patches: **list** of **string**, all patches need to be in 'p1' level&lt;br /&gt;
&lt;br /&gt;
* Requires: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPre: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPreUn: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPost: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* RequiresPostUn: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* PkgBR: **list** of **string**, packages required by build, or BuildRequires&lt;br /&gt;
&lt;br /&gt;
* PkgConfigBR: **list** of **string**, pkg-config requires by build&lt;br /&gt;
&lt;br /&gt;
* Provides: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Conflicts: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Obsoletes: **list** of **string**&lt;br /&gt;
&lt;br /&gt;
* Configure: **string**, *optional*, valid values: **autogen**, **configure**, **reconfigure**, **none**&amp;lt;br&amp;gt;&lt;br /&gt;
**If not specified, the default value ``configure`` will be used**&lt;br /&gt;
&lt;br /&gt;
* Builder: **string**, *optional*, valid values: **make**, **single-make**, **python**, **perl**, **none**&amp;lt;br&amp;gt;&lt;br /&gt;
**If not specified, the default value ``make`` will be used. If do not want an automatic builder, please use ``none``.**&lt;br /&gt;
&lt;br /&gt;
* Files: **list** of **string**, *optional*, content of ``%files`` for small packages&lt;br /&gt;
&lt;br /&gt;
* FilesInput: **string**, *optional*, extra input source for %files&lt;br /&gt;
&lt;br /&gt;
* NoFiles: **boolean**, *optional*, if to be set as True, means no %files section for this package and it cause no rpm generated&lt;br /&gt;
&lt;br /&gt;
* RunFdupes: **string**, parameters of ``fdupes`` in %install&lt;br /&gt;
&lt;br /&gt;
* RpmLintIgnore: **list**, *optional*, list of skip items for ``rpmlint``&lt;br /&gt;
&lt;br /&gt;
* Check: **boolean**, whether need ``%check`` section in spec&lt;br /&gt;
&lt;br /&gt;
* SupportOtherDistros: **boolean**, whether need to check for other distros (besides MeeGo)&lt;br /&gt;
&lt;br /&gt;
* UseAsNeeded: **boolean**, whether export LD_AS_NEEDED=1 env when building&lt;br /&gt;
&lt;br /&gt;
* NoAutoReq: **boolean**, whether add 'AutoReq: 0' to spec&lt;br /&gt;
&lt;br /&gt;
* NoAutoProv: **boolean**, whether add 'AutoProv: 0' to spec&lt;br /&gt;
&lt;br /&gt;
* NoSetup: **boolean**, whether to skip using ``%setup`` in ``%prep``&lt;br /&gt;
&lt;br /&gt;
* NoAutoLocale: **boolean**, whether to use ``%find_lang`` to search locale data when found 'inittool' in PkgBR&lt;br /&gt;
&lt;br /&gt;
* NoDesktop: **boolean**, whether to install the desktop files in package&lt;br /&gt;
&lt;br /&gt;
* UpdateDesktopDB: **boolean**, whether to run 'update-desktop-database' to flush cache when package (un)installation&lt;br /&gt;
&lt;br /&gt;
* AutoDepend: **boolean**, for subpackages only, whether to add Require to main package automatically&lt;br /&gt;
&lt;br /&gt;
* AsWholeName: **boolean**, for subpackages only, whether to use **Name** as the whole package name&lt;br /&gt;
&lt;br /&gt;
* AutoSubPackages: **list** of **string**, mainly for '-devel'&lt;br /&gt;
&lt;br /&gt;
* SubPackages: **list** of **dict**, the **dict** item is the lower level directives for sub packages:&lt;br /&gt;
    * Name&lt;br /&gt;
    * Summary&lt;br /&gt;
    * Description, *optional*&lt;br /&gt;
    * Group, *optional*&lt;br /&gt;
    * Requires, *optional*&lt;br /&gt;
    * FilesInput, *optional*&lt;br /&gt;
    * etc.&lt;br /&gt;
&lt;br /&gt;
CAUTION: The following cases of value string have special meaning in YAML syntax:&lt;br /&gt;
    * string with leading **``%``** charactor&lt;br /&gt;
    * string with leading **``*``** charactor&lt;br /&gt;
    * string contains **``:``** charactor and one or more spaces/tabs after **``:``**&lt;br /&gt;
Then these string values need to be quoted by ``'``(single-quote) or ``&amp;quot;`` (double-quote), and the choice of quote char should not conflict with the value string self.**&lt;br /&gt;
&lt;br /&gt;
== Namespace support for multi-architecture in several keywords ==&lt;br /&gt;
For the following spectacle YAML keywords:&lt;br /&gt;
&lt;br /&gt;
* Requires&lt;br /&gt;
* PkgBR&lt;br /&gt;
* PkgConfigBR&lt;br /&gt;
* Patches&lt;br /&gt;
* ConfigOptions&lt;br /&gt;
&lt;br /&gt;
If one of the items need to be architecture specified, we can add arch prefix to&lt;br /&gt;
it. The supported prefix and the corresponding architectures as the followings:&lt;br /&gt;
&lt;br /&gt;
* ``ix86:`` -   x86 platform&lt;br /&gt;
* ``arm:``  -   arm platform&lt;br /&gt;
&lt;br /&gt;
Here's some samples:&lt;br /&gt;
&lt;br /&gt;
    Requires:&lt;br /&gt;
        - arm:pkg-need-in-arm-image&lt;br /&gt;
        - ix86:pkg-need-in-x86-image&lt;br /&gt;
        - normal-pkg&lt;br /&gt;
    ConfigOptions:&lt;br /&gt;
        - arm:--arm-specific-opt&lt;br /&gt;
        - ix86:--ix86-specific-opt&lt;br /&gt;
        - --common-opt&lt;br /&gt;
&lt;br /&gt;
== Customizations in spec ==&lt;br /&gt;
Generated spec files by specify will have many placeholders for customizations,&lt;br /&gt;
such as:&lt;br /&gt;
&lt;br /&gt;
    # &amp;gt;&amp;gt; build pre&lt;br /&gt;
    # &amp;lt;&amp;lt; build pre&lt;br /&gt;
&lt;br /&gt;
You can add any custom code between the markers, next time when you run&lt;br /&gt;
``specify``, the text between the markers will be kept as is, all other sections&lt;br /&gt;
relying on the meta data from the YAML file will be changed depending on the&lt;br /&gt;
values in the YAML file.&lt;br /&gt;
&lt;br /&gt;
The following placeholders in spec can be customized:&lt;br /&gt;
&lt;br /&gt;
* Private Macros, used in this package's spec&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; macros&lt;br /&gt;
        # &amp;lt;&amp;lt; macros&lt;br /&gt;
&lt;br /&gt;
* Extra setup scripts in the last of ``%prep``&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; setup&lt;br /&gt;
        # &amp;lt;&amp;lt; setup&lt;br /&gt;
&lt;br /&gt;
* Pre-Build, scripts before package building&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; build pre&lt;br /&gt;
        # &amp;lt;&amp;lt; build pre&lt;br /&gt;
&lt;br /&gt;
* Post-Build, scripts after package building&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; build post&lt;br /&gt;
        # &amp;lt;&amp;lt; build post&lt;br /&gt;
&lt;br /&gt;
* Pre-Install, scripts before package installation&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; install pre&lt;br /&gt;
        # &amp;lt;&amp;lt; install pre&lt;br /&gt;
&lt;br /&gt;
* Post-Install, scripts after package installation&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; install post&lt;br /&gt;
        # &amp;lt;&amp;lt; install post&lt;br /&gt;
&lt;br /&gt;
* Files, files list in packaged rpm&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; files [sub-package]&lt;br /&gt;
        # &amp;lt;&amp;lt; files [sub-package]&lt;br /&gt;
NOTE**: &amp;quot;sub-packge&amp;quot; stands for the name of sub-package, and it is optional. If no sub-package name specified, it means the files of **main** package.&lt;br /&gt;
NOTE**: If the file list is simple enough, you can use YAML *Files* keyword instead to record it.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %check section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; check&lt;br /&gt;
        # &amp;lt;&amp;lt; check&lt;br /&gt;
NOTE**: Only if YAML boolean *Check* is specifed as ``yes``, %check with placeholder lines will be generated in .spec.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %pre section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; pre&lt;br /&gt;
        # &amp;lt;&amp;lt; pre&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %preun section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; preun&lt;br /&gt;
        # &amp;lt;&amp;lt; preun&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %post section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; post&lt;br /&gt;
        # &amp;lt;&amp;lt; post&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* Scriptlets for %postun section&lt;br /&gt;
&lt;br /&gt;
    With placeholder:&lt;br /&gt;
        # &amp;gt;&amp;gt; postun&lt;br /&gt;
        # &amp;lt;&amp;lt; postun&lt;br /&gt;
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.&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Quality/Compliance_tools</id>
		<title>Quality/Compliance tools</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Quality/Compliance_tools"/>
				<updated>2010-10-29T12:11:28Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* TODO */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Introduction =&lt;br /&gt;
&lt;br /&gt;
Compliance tools are used to check MeeGo compliance for MeeGo Distributions or MeeGo Applications. The compliance reference input is the MeeGo core package/file list and a minimal MeeGo reference image created by MIC2, which will contain all the required core packages, as well as src rpms.&lt;br /&gt;
&lt;br /&gt;
For MeeGo distribution compliance checking, the input needs to include the OS image and the src.rpms for all the packages. And for MeeGo Application compliance checking, the input is the application rpm file.&lt;br /&gt;
&lt;br /&gt;
The tools will generate report files (in HTML currently) to show the result.&lt;br /&gt;
&lt;br /&gt;
= Installation =&lt;br /&gt;
Compliance tools can be installed using released rpm and deb packages, or installed by source code.&lt;br /&gt;
&lt;br /&gt;
== Packages and Repos ==&lt;br /&gt;
The package in the MeeGo OBS server for this project is [http://build.meego.com/package/show?package=meego-compliance-tools&amp;amp;project=devel:tools:building devel:tools:building/meego-compliance-tools]. And all the rpm and deb packages for release can be generated by the OBS server. The following Linux distributions are supported:&lt;br /&gt;
&lt;br /&gt;
* Debian 5.0&lt;br /&gt;
* xUbuntu 9.10, 10.04, 10.10&lt;br /&gt;
* Fedora 11, 12, 13&lt;br /&gt;
* openSUSE 11.1, 11.2, 11.3&lt;br /&gt;
* MeeGo 1.0, Trunk (1.2)&lt;br /&gt;
&lt;br /&gt;
The corresponding software repos can be used to install the tools conveniently. Whenever the feature and quality of code are stable enough, the packages and repos will be published at repo.meego.com.&lt;br /&gt;
For rpm packaging ditros, there are three packages available:&lt;br /&gt;
* meego-compliance-tools (common data, will be installed automatically as the dependency of the two packages below)&lt;br /&gt;
* meego-dist-compliance-tools (for MeeGo distro compliance checking)&lt;br /&gt;
* meego-app-compliance-tools. (for MeeGo application compliance checking)&lt;br /&gt;
&lt;br /&gt;
== Source Code ==&lt;br /&gt;
The tools can also be installed by source code. After fetching the code, under the code directory, run:&lt;br /&gt;
  $ [sudo] make install&lt;br /&gt;
&lt;br /&gt;
The source code is hosted at:&lt;br /&gt;
  [http://meego.gitorious.org/meego-developer-tools/meego-compliance-tools meego-compliance-tools@gitorious.org]&lt;br /&gt;
&lt;br /&gt;
== MIC2 ==&lt;br /&gt;
To prepare the images used in compliance tools, you need [[Image_Creation|MIC2]] with new features (version 0.22.0 or later).&lt;br /&gt;
&lt;br /&gt;
=  Features =&lt;br /&gt;
== dist-compliance-tool ==&lt;br /&gt;
It executes compliance checking for MeeGo distributions. The following features are supported:&lt;br /&gt;
* Binary pkg comparison:&lt;br /&gt;
** Exist in target image?&lt;br /&gt;
** Version matches the requirement?&lt;br /&gt;
*** flexible version checking: support rules with comparison operators like &amp;quot;&amp;gt;=&amp;quot; in core pkg list&lt;br /&gt;
* Content in source rpm comparison:&lt;br /&gt;
** This step will be skipped if binary rpm checking fails&lt;br /&gt;
** Spec filename&lt;br /&gt;
** Spec content&lt;br /&gt;
** Sources and md5sum&lt;br /&gt;
** Patches and the content&lt;br /&gt;
&lt;br /&gt;
== app-compliance-tool ==&lt;br /&gt;
For compliance checking for MeeGo applications, the following features are supported:&lt;br /&gt;
* check if all dependent packages exist in core package list&lt;br /&gt;
* check if the target package can be installed in the minimal image&lt;br /&gt;
* verify the installation location of the application&lt;br /&gt;
* verify the minimal requirement of the desktop file and icon for the application&lt;br /&gt;
&lt;br /&gt;
= Usage =&lt;br /&gt;
== Image Preparation ==&lt;br /&gt;
Before using the tools, the reference image needs to be created by using MIC2 (version 0.22.0 or later):&lt;br /&gt;
  $ [sudo] mic-image-creator --run-mode=0 --cache=mycachedir --format=fs  --config=&amp;lt;ks file&amp;gt; --package=tar.bz2 --include-source&lt;br /&gt;
The sample ks file can be downloaded at:&lt;br /&gt;
  [[media:Meego-minimal-compliance-1.0.99.1.ks]]&lt;br /&gt;
The sample core list file can be downloaded at:&lt;br /&gt;
  [[media:Core-list-1.0.99.1‎]]&lt;br /&gt;
And the ks file and core list should be synced with and conform to the latest [[Quality/Compliance|MeeGo compliance spec]].&lt;br /&gt;
&lt;br /&gt;
To try the dist compliance check tool (dist_compliance.sh), please prepare a target image as the input. The target image can be generated by using the same method as the above.&lt;br /&gt;
&lt;br /&gt;
== Devices Compliance Check ==&lt;br /&gt;
The command &amp;quot;dist_complianc&amp;quot; is for checking compliance of MeeGo devices, or distributions.&lt;br /&gt;
&lt;br /&gt;
     Usage: [sudo] dist_compliance [options]&lt;br /&gt;
     Options:&lt;br /&gt;
        --version             show program's version number and exit&lt;br /&gt;
        -h, --help            show this help message and exit&lt;br /&gt;
        -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                              File to store core list of MeeGo&lt;br /&gt;
        -r REFIMAGE, --refimage=REFIMAGE&lt;br /&gt;
                              Filepath of reference image&lt;br /&gt;
        -t TGTIMAGE, --tgtimage=TGTIMAGE&lt;br /&gt;
                              Filepath of target image&lt;br /&gt;
        -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                              Output directory of report&lt;br /&gt;
&lt;br /&gt;
== Apps Compliance Check ==&lt;br /&gt;
The command &amp;quot;app_compliance&amp;quot; is for applications compliance checking.&lt;br /&gt;
&lt;br /&gt;
    Usage: [sudo] app_compliance [options] &amp;lt;app-rpm&amp;gt;&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -r REFIMAGE, --refimage=REFIMAGE&lt;br /&gt;
                            Filepath of reference image&lt;br /&gt;
      -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                            File to store core list of MeeGo&lt;br /&gt;
      -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                            Output directory of report&lt;br /&gt;
&lt;br /&gt;
= Result Format =&lt;br /&gt;
Currently, the output of checking tools will be store in HTML files.&lt;br /&gt;
Screen capture of sample distribution report:&lt;br /&gt;
[[File:DistSummaryReport.png|none|600px|Sample Report]]&lt;br /&gt;
&lt;br /&gt;
= Bug Reoprt =&lt;br /&gt;
&lt;br /&gt;
If problems were found in compliance tools, please file bugs in bugs.meego.com.&lt;br /&gt;
The corresponding section is: &amp;quot;Development Tools/Tools&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
= TODO =&lt;br /&gt;
&lt;br /&gt;
* add checking for contents of binary packages&lt;br /&gt;
* architecture re-design and code update&lt;br /&gt;
* use new image format with separated src.rpm pack&lt;br /&gt;
* web UI&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Quality/Compliance_tools</id>
		<title>Quality/Compliance tools</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Quality/Compliance_tools"/>
				<updated>2010-10-29T12:10:27Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* Apps Compliance Check */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Introduction =&lt;br /&gt;
&lt;br /&gt;
Compliance tools are used to check MeeGo compliance for MeeGo Distributions or MeeGo Applications. The compliance reference input is the MeeGo core package/file list and a minimal MeeGo reference image created by MIC2, which will contain all the required core packages, as well as src rpms.&lt;br /&gt;
&lt;br /&gt;
For MeeGo distribution compliance checking, the input needs to include the OS image and the src.rpms for all the packages. And for MeeGo Application compliance checking, the input is the application rpm file.&lt;br /&gt;
&lt;br /&gt;
The tools will generate report files (in HTML currently) to show the result.&lt;br /&gt;
&lt;br /&gt;
= Installation =&lt;br /&gt;
Compliance tools can be installed using released rpm and deb packages, or installed by source code.&lt;br /&gt;
&lt;br /&gt;
== Packages and Repos ==&lt;br /&gt;
The package in the MeeGo OBS server for this project is [http://build.meego.com/package/show?package=meego-compliance-tools&amp;amp;project=devel:tools:building devel:tools:building/meego-compliance-tools]. And all the rpm and deb packages for release can be generated by the OBS server. The following Linux distributions are supported:&lt;br /&gt;
&lt;br /&gt;
* Debian 5.0&lt;br /&gt;
* xUbuntu 9.10, 10.04, 10.10&lt;br /&gt;
* Fedora 11, 12, 13&lt;br /&gt;
* openSUSE 11.1, 11.2, 11.3&lt;br /&gt;
* MeeGo 1.0, Trunk (1.2)&lt;br /&gt;
&lt;br /&gt;
The corresponding software repos can be used to install the tools conveniently. Whenever the feature and quality of code are stable enough, the packages and repos will be published at repo.meego.com.&lt;br /&gt;
For rpm packaging ditros, there are three packages available:&lt;br /&gt;
* meego-compliance-tools (common data, will be installed automatically as the dependency of the two packages below)&lt;br /&gt;
* meego-dist-compliance-tools (for MeeGo distro compliance checking)&lt;br /&gt;
* meego-app-compliance-tools. (for MeeGo application compliance checking)&lt;br /&gt;
&lt;br /&gt;
== Source Code ==&lt;br /&gt;
The tools can also be installed by source code. After fetching the code, under the code directory, run:&lt;br /&gt;
  $ [sudo] make install&lt;br /&gt;
&lt;br /&gt;
The source code is hosted at:&lt;br /&gt;
  [http://meego.gitorious.org/meego-developer-tools/meego-compliance-tools meego-compliance-tools@gitorious.org]&lt;br /&gt;
&lt;br /&gt;
== MIC2 ==&lt;br /&gt;
To prepare the images used in compliance tools, you need [[Image_Creation|MIC2]] with new features (version 0.22.0 or later).&lt;br /&gt;
&lt;br /&gt;
=  Features =&lt;br /&gt;
== dist-compliance-tool ==&lt;br /&gt;
It executes compliance checking for MeeGo distributions. The following features are supported:&lt;br /&gt;
* Binary pkg comparison:&lt;br /&gt;
** Exist in target image?&lt;br /&gt;
** Version matches the requirement?&lt;br /&gt;
*** flexible version checking: support rules with comparison operators like &amp;quot;&amp;gt;=&amp;quot; in core pkg list&lt;br /&gt;
* Content in source rpm comparison:&lt;br /&gt;
** This step will be skipped if binary rpm checking fails&lt;br /&gt;
** Spec filename&lt;br /&gt;
** Spec content&lt;br /&gt;
** Sources and md5sum&lt;br /&gt;
** Patches and the content&lt;br /&gt;
&lt;br /&gt;
== app-compliance-tool ==&lt;br /&gt;
For compliance checking for MeeGo applications, the following features are supported:&lt;br /&gt;
* check if all dependent packages exist in core package list&lt;br /&gt;
* check if the target package can be installed in the minimal image&lt;br /&gt;
* verify the installation location of the application&lt;br /&gt;
* verify the minimal requirement of the desktop file and icon for the application&lt;br /&gt;
&lt;br /&gt;
= Usage =&lt;br /&gt;
== Image Preparation ==&lt;br /&gt;
Before using the tools, the reference image needs to be created by using MIC2 (version 0.22.0 or later):&lt;br /&gt;
  $ [sudo] mic-image-creator --run-mode=0 --cache=mycachedir --format=fs  --config=&amp;lt;ks file&amp;gt; --package=tar.bz2 --include-source&lt;br /&gt;
The sample ks file can be downloaded at:&lt;br /&gt;
  [[media:Meego-minimal-compliance-1.0.99.1.ks]]&lt;br /&gt;
The sample core list file can be downloaded at:&lt;br /&gt;
  [[media:Core-list-1.0.99.1‎]]&lt;br /&gt;
And the ks file and core list should be synced with and conform to the latest [[Quality/Compliance|MeeGo compliance spec]].&lt;br /&gt;
&lt;br /&gt;
To try the dist compliance check tool (dist_compliance.sh), please prepare a target image as the input. The target image can be generated by using the same method as the above.&lt;br /&gt;
&lt;br /&gt;
== Devices Compliance Check ==&lt;br /&gt;
The command &amp;quot;dist_complianc&amp;quot; is for checking compliance of MeeGo devices, or distributions.&lt;br /&gt;
&lt;br /&gt;
     Usage: [sudo] dist_compliance [options]&lt;br /&gt;
     Options:&lt;br /&gt;
        --version             show program's version number and exit&lt;br /&gt;
        -h, --help            show this help message and exit&lt;br /&gt;
        -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                              File to store core list of MeeGo&lt;br /&gt;
        -r REFIMAGE, --refimage=REFIMAGE&lt;br /&gt;
                              Filepath of reference image&lt;br /&gt;
        -t TGTIMAGE, --tgtimage=TGTIMAGE&lt;br /&gt;
                              Filepath of target image&lt;br /&gt;
        -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                              Output directory of report&lt;br /&gt;
&lt;br /&gt;
== Apps Compliance Check ==&lt;br /&gt;
The command &amp;quot;app_compliance&amp;quot; is for applications compliance checking.&lt;br /&gt;
&lt;br /&gt;
    Usage: [sudo] app_compliance [options] &amp;lt;app-rpm&amp;gt;&lt;br /&gt;
    Options:&lt;br /&gt;
      --version             show program's version number and exit&lt;br /&gt;
      -h, --help            show this help message and exit&lt;br /&gt;
      -r REFIMAGE, --refimage=REFIMAGE&lt;br /&gt;
                            Filepath of reference image&lt;br /&gt;
      -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                            File to store core list of MeeGo&lt;br /&gt;
      -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                            Output directory of report&lt;br /&gt;
&lt;br /&gt;
= Result Format =&lt;br /&gt;
Currently, the output of checking tools will be store in HTML files.&lt;br /&gt;
Screen capture of sample distribution report:&lt;br /&gt;
[[File:DistSummaryReport.png|none|600px|Sample Report]]&lt;br /&gt;
&lt;br /&gt;
= Bug Reoprt =&lt;br /&gt;
&lt;br /&gt;
If problems were found in compliance tools, please file bugs in bugs.meego.com.&lt;br /&gt;
The corresponding section is: &amp;quot;Development Tools/Tools&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
= TODO =&lt;br /&gt;
&lt;br /&gt;
* re-implement shell scripts with python&lt;br /&gt;
* add checking for contents of binary packages&lt;br /&gt;
* architecture re-design and code update&lt;br /&gt;
* use new image format with separated src.rpm pack&lt;br /&gt;
* web UI&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Quality/Compliance_tools</id>
		<title>Quality/Compliance tools</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Quality/Compliance_tools"/>
				<updated>2010-10-29T12:09:18Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* Devices Compliance Check */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Introduction =&lt;br /&gt;
&lt;br /&gt;
Compliance tools are used to check MeeGo compliance for MeeGo Distributions or MeeGo Applications. The compliance reference input is the MeeGo core package/file list and a minimal MeeGo reference image created by MIC2, which will contain all the required core packages, as well as src rpms.&lt;br /&gt;
&lt;br /&gt;
For MeeGo distribution compliance checking, the input needs to include the OS image and the src.rpms for all the packages. And for MeeGo Application compliance checking, the input is the application rpm file.&lt;br /&gt;
&lt;br /&gt;
The tools will generate report files (in HTML currently) to show the result.&lt;br /&gt;
&lt;br /&gt;
= Installation =&lt;br /&gt;
Compliance tools can be installed using released rpm and deb packages, or installed by source code.&lt;br /&gt;
&lt;br /&gt;
== Packages and Repos ==&lt;br /&gt;
The package in the MeeGo OBS server for this project is [http://build.meego.com/package/show?package=meego-compliance-tools&amp;amp;project=devel:tools:building devel:tools:building/meego-compliance-tools]. And all the rpm and deb packages for release can be generated by the OBS server. The following Linux distributions are supported:&lt;br /&gt;
&lt;br /&gt;
* Debian 5.0&lt;br /&gt;
* xUbuntu 9.10, 10.04, 10.10&lt;br /&gt;
* Fedora 11, 12, 13&lt;br /&gt;
* openSUSE 11.1, 11.2, 11.3&lt;br /&gt;
* MeeGo 1.0, Trunk (1.2)&lt;br /&gt;
&lt;br /&gt;
The corresponding software repos can be used to install the tools conveniently. Whenever the feature and quality of code are stable enough, the packages and repos will be published at repo.meego.com.&lt;br /&gt;
For rpm packaging ditros, there are three packages available:&lt;br /&gt;
* meego-compliance-tools (common data, will be installed automatically as the dependency of the two packages below)&lt;br /&gt;
* meego-dist-compliance-tools (for MeeGo distro compliance checking)&lt;br /&gt;
* meego-app-compliance-tools. (for MeeGo application compliance checking)&lt;br /&gt;
&lt;br /&gt;
== Source Code ==&lt;br /&gt;
The tools can also be installed by source code. After fetching the code, under the code directory, run:&lt;br /&gt;
  $ [sudo] make install&lt;br /&gt;
&lt;br /&gt;
The source code is hosted at:&lt;br /&gt;
  [http://meego.gitorious.org/meego-developer-tools/meego-compliance-tools meego-compliance-tools@gitorious.org]&lt;br /&gt;
&lt;br /&gt;
== MIC2 ==&lt;br /&gt;
To prepare the images used in compliance tools, you need [[Image_Creation|MIC2]] with new features (version 0.22.0 or later).&lt;br /&gt;
&lt;br /&gt;
=  Features =&lt;br /&gt;
== dist-compliance-tool ==&lt;br /&gt;
It executes compliance checking for MeeGo distributions. The following features are supported:&lt;br /&gt;
* Binary pkg comparison:&lt;br /&gt;
** Exist in target image?&lt;br /&gt;
** Version matches the requirement?&lt;br /&gt;
*** flexible version checking: support rules with comparison operators like &amp;quot;&amp;gt;=&amp;quot; in core pkg list&lt;br /&gt;
* Content in source rpm comparison:&lt;br /&gt;
** This step will be skipped if binary rpm checking fails&lt;br /&gt;
** Spec filename&lt;br /&gt;
** Spec content&lt;br /&gt;
** Sources and md5sum&lt;br /&gt;
** Patches and the content&lt;br /&gt;
&lt;br /&gt;
== app-compliance-tool ==&lt;br /&gt;
For compliance checking for MeeGo applications, the following features are supported:&lt;br /&gt;
* check if all dependent packages exist in core package list&lt;br /&gt;
* check if the target package can be installed in the minimal image&lt;br /&gt;
* verify the installation location of the application&lt;br /&gt;
* verify the minimal requirement of the desktop file and icon for the application&lt;br /&gt;
&lt;br /&gt;
= Usage =&lt;br /&gt;
== Image Preparation ==&lt;br /&gt;
Before using the tools, the reference image needs to be created by using MIC2 (version 0.22.0 or later):&lt;br /&gt;
  $ [sudo] mic-image-creator --run-mode=0 --cache=mycachedir --format=fs  --config=&amp;lt;ks file&amp;gt; --package=tar.bz2 --include-source&lt;br /&gt;
The sample ks file can be downloaded at:&lt;br /&gt;
  [[media:Meego-minimal-compliance-1.0.99.1.ks]]&lt;br /&gt;
The sample core list file can be downloaded at:&lt;br /&gt;
  [[media:Core-list-1.0.99.1‎]]&lt;br /&gt;
And the ks file and core list should be synced with and conform to the latest [[Quality/Compliance|MeeGo compliance spec]].&lt;br /&gt;
&lt;br /&gt;
To try the dist compliance check tool (dist_compliance.sh), please prepare a target image as the input. The target image can be generated by using the same method as the above.&lt;br /&gt;
&lt;br /&gt;
== Devices Compliance Check ==&lt;br /&gt;
The command &amp;quot;dist_complianc&amp;quot; is for checking compliance of MeeGo devices, or distributions.&lt;br /&gt;
&lt;br /&gt;
     Usage: [sudo] dist_compliance [options]&lt;br /&gt;
     Options:&lt;br /&gt;
        --version             show program's version number and exit&lt;br /&gt;
        -h, --help            show this help message and exit&lt;br /&gt;
        -c CORELIST, --corelist=CORELIST&lt;br /&gt;
                              File to store core list of MeeGo&lt;br /&gt;
        -r REFIMAGE, --refimage=REFIMAGE&lt;br /&gt;
                              Filepath of reference image&lt;br /&gt;
        -t TGTIMAGE, --tgtimage=TGTIMAGE&lt;br /&gt;
                              Filepath of target image&lt;br /&gt;
        -o OUTDIR, --outdir=OUTDIR&lt;br /&gt;
                              Output directory of report&lt;br /&gt;
&lt;br /&gt;
== Apps Compliance Check ==&lt;br /&gt;
The executable script &amp;quot;app_compliance.sh&amp;quot; is for applications compliance checking.&lt;br /&gt;
&lt;br /&gt;
        Usage: [sudo] app_compliance -p pkg_file -t reference_img_bz2 -c pkglist_file&lt;br /&gt;
        Options:&lt;br /&gt;
        -p pkgfile of the app which to be tested&lt;br /&gt;
        -t reference_img_bz2 which is the image to install the package.&lt;br /&gt;
        -c the core package list in minimal image&lt;br /&gt;
&lt;br /&gt;
= Result Format =&lt;br /&gt;
Currently, the output of checking tools will be store in HTML files.&lt;br /&gt;
Screen capture of sample distribution report:&lt;br /&gt;
[[File:DistSummaryReport.png|none|600px|Sample Report]]&lt;br /&gt;
&lt;br /&gt;
= Bug Reoprt =&lt;br /&gt;
&lt;br /&gt;
If problems were found in compliance tools, please file bugs in bugs.meego.com.&lt;br /&gt;
The corresponding section is: &amp;quot;Development Tools/Tools&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
= TODO =&lt;br /&gt;
&lt;br /&gt;
* re-implement shell scripts with python&lt;br /&gt;
* add checking for contents of binary packages&lt;br /&gt;
* architecture re-design and code update&lt;br /&gt;
* use new image format with separated src.rpm pack&lt;br /&gt;
* web UI&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Quality/Compliance_tools</id>
		<title>Quality/Compliance tools</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Quality/Compliance_tools"/>
				<updated>2010-10-22T10:29:37Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Introduction =&lt;br /&gt;
&lt;br /&gt;
Compliance tools are used to check MeeGo compliance for MeeGo Distributions or MeeGo Applications. The compliance reference input is the MeeGo core package/file list and a minimal MeeGo reference image created by MIC2, which will contain all the required core packages, as well as src rpms.&lt;br /&gt;
&lt;br /&gt;
For MeeGo distribution compliance checking, the input needs to include the OS image and the src.rpms for all the packages. And for MeeGo Application compliance checking, the input is the application rpm file.&lt;br /&gt;
&lt;br /&gt;
The tools will generate report files (in HTML currently) to show the result.&lt;br /&gt;
&lt;br /&gt;
= Installation =&lt;br /&gt;
Compliance tools can be installed by released rpm and deb packages, or installed by source code.&lt;br /&gt;
&lt;br /&gt;
== Packages and Repos ==&lt;br /&gt;
The package in the MeeGo OBS server for this project is [http://build.meego.com/package/show?package=meego-compliance-tools&amp;amp;project=devel:tools:building devel:tools:building/meego-compliance-tools]. And all the rpm and deb packages for release can be generated by the OBS server. The following Linux distributions are supported:&lt;br /&gt;
&lt;br /&gt;
* Debian 5.0&lt;br /&gt;
* xUbuntu 9.10, 10.04, 10.10&lt;br /&gt;
* Fedora 11, 12, 13&lt;br /&gt;
* openSUSE 11.1, 11.2, 11.3&lt;br /&gt;
* MeeGo 1.0, Trunk (1.2)&lt;br /&gt;
&lt;br /&gt;
The corresponding software repos can be used to install the tools conveniently. Whenever the feature and quality of code are stable enough, the packages and repos will be published at repo.meego.com.&lt;br /&gt;
For rpm packaging ditros, there are three packages available:&lt;br /&gt;
* meego-compliance-tools (common data, will be installed automatically as the dependency of the two packages below)&lt;br /&gt;
* meego-dist-compliance-tools (for MeeGo distro compliance checking)&lt;br /&gt;
* meego-app-compliance-tools. (for MeeGo application compliance checking)&lt;br /&gt;
&lt;br /&gt;
== Source Code ==&lt;br /&gt;
The tools can also be installed by source code. After fetching the code, under the code directory, run:&lt;br /&gt;
  $ [sudo] make install&lt;br /&gt;
&lt;br /&gt;
The source code is hosted at:&lt;br /&gt;
  [http://meego.gitorious.org/meego-developer-tools/meego-compliance-tools meego-compliance-tools@gitorious.org]&lt;br /&gt;
&lt;br /&gt;
== MIC2 ==&lt;br /&gt;
To prepare the images used in compliance tools, you need [[Image_Creation|MIC2]] with new features (version 0.22.0 or later).&lt;br /&gt;
&lt;br /&gt;
=  Features =&lt;br /&gt;
== dist-compliance-tool ==&lt;br /&gt;
It executes compliance checking for MeeGo distributions. The following features are supported:&lt;br /&gt;
* Binary pkg comparison:&lt;br /&gt;
** Exist in target image?&lt;br /&gt;
** Version matches the requirement?&lt;br /&gt;
*** flexible version checking: support rules with comparison operators like &amp;quot;&amp;gt;=&amp;quot; in core pkg list&lt;br /&gt;
* Content in source rpm comparison:&lt;br /&gt;
** This step will be skipped if binary rpm checking fails&lt;br /&gt;
** Spec filename&lt;br /&gt;
** Spec content&lt;br /&gt;
** Sources and md5sum&lt;br /&gt;
** Patches and the content&lt;br /&gt;
&lt;br /&gt;
== app-compliance-tool ==&lt;br /&gt;
For compliance checking for MeeGo applications, the following features are supported:&lt;br /&gt;
* check if all dependent packages exist in core package list&lt;br /&gt;
* check if the target package can be install in the minimal image&lt;br /&gt;
* verify the installation location of the application&lt;br /&gt;
* verify the minimal requirement of the desktop file and icon for the application&lt;br /&gt;
&lt;br /&gt;
= Usage =&lt;br /&gt;
== Images Prepare ==&lt;br /&gt;
Before using the tools, the reference image need to be created by using MIC2 (version 0.22.0 or later):&lt;br /&gt;
  $ [sudo] mic-image-creator --run-mode=0 --cache=mycachedir --format=fs  --config=&amp;lt;ks file&amp;gt; --package=tar.bz2 --include-source&lt;br /&gt;
The sample ks file can be downloaded at:&lt;br /&gt;
  [[media:Meego-minimal-compliance-1.0.99.1.ks]]&lt;br /&gt;
The sample core list file can be downloaded at:&lt;br /&gt;
  [[media:Core-list-1.0.99.1‎]]&lt;br /&gt;
And the ks file and core list should be synced with and conform to the latest [[Quality/Compliance|MeeGo compliance spec]].&lt;br /&gt;
&lt;br /&gt;
To try the dist compliance check tool (dist_compliance.sh), please prepare a target image as the input. The target image can be generated by using the same method as the above.&lt;br /&gt;
&lt;br /&gt;
== Devices Compliance Check ==&lt;br /&gt;
The executable script &amp;quot;dist_complianc.sh&amp;quot; is for checking compliance of MeeGo devices, or distributions.&lt;br /&gt;
&lt;br /&gt;
        Usage: [sudo] dist_compliance [-h] [-p pkglist_file] -r reference_img_bz2 -t target_img_bz2&lt;br /&gt;
        Options:&lt;br /&gt;
        -p pkglist_file&lt;br /&gt;
           the file which contain the package list, this option is optional&lt;br /&gt;
           If the option -p is not provided, will take all the packages in the reference image&lt;br /&gt;
        -r reference_img_bz2&lt;br /&gt;
           bz2 format image, the minimal compliance image&lt;br /&gt;
        -t target_img_bz2&lt;br /&gt;
           bz2 format image, the target image to be scaned&lt;br /&gt;
        -h show help usage.&lt;br /&gt;
&lt;br /&gt;
== Apps Compliance Check ==&lt;br /&gt;
The executable script &amp;quot;app_compliance.sh&amp;quot; is for applications compliance checking.&lt;br /&gt;
&lt;br /&gt;
        Usage: [sudo] app_compliance -p pkg_file -t reference_img_bz2 -c pkglist_file&lt;br /&gt;
        Options:&lt;br /&gt;
        -p pkgfile of the app which to be tested&lt;br /&gt;
        -t reference_img_bz2 which is the image to install the package.&lt;br /&gt;
        -c the core package list in minimal image&lt;br /&gt;
&lt;br /&gt;
= Result Format =&lt;br /&gt;
Currently, the output of checking tools will be store in HTML files.&lt;br /&gt;
Screen capture of sample distribution report:&lt;br /&gt;
[[File:DistSummaryReport.png|none|600px|Sample Report]]&lt;br /&gt;
&lt;br /&gt;
= Bug Reoprt =&lt;br /&gt;
&lt;br /&gt;
If problems were found in compliance tools, please file bugs in bugs.meego.com.&lt;br /&gt;
The corresponding section is: &amp;quot;Development Tools/Tools&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
= TODO =&lt;br /&gt;
&lt;br /&gt;
* re-implement shell scripts with python&lt;br /&gt;
* add checking for contents of binary packages&lt;br /&gt;
* architecture re-design and code update&lt;br /&gt;
* use new image format with separated src.rpm pack&lt;br /&gt;
* web UI&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Quality/Compliance_tools</id>
		<title>Quality/Compliance tools</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Quality/Compliance_tools"/>
				<updated>2010-10-22T10:18:36Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: Created page with &amp;quot;= Introduction =  Compliance tools are used to check MeeGo compliance for MeeGo Distributions or MeeGo Applications. The compliance reference input is the MeeGo core package/file…&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Introduction =&lt;br /&gt;
&lt;br /&gt;
Compliance tools are used to check MeeGo compliance for MeeGo Distributions or MeeGo Applications. The compliance reference input is the MeeGo core package/file list and a minimal MeeGo reference image created by MIC2, which will contain all the required core packages, as well as src rpms.&lt;br /&gt;
&lt;br /&gt;
For MeeGo distribution compliance checking, the input needs to include the OS image and the src.rpms for all the packages. And for MeeGo Application compliance checking, the input is the application rpm file.&lt;br /&gt;
&lt;br /&gt;
The tools will generate report files (in HTML currently) to show the result.&lt;br /&gt;
&lt;br /&gt;
= Installation =&lt;br /&gt;
Compliance tools can be installed by released rpm and deb packages, or installed by source code.&lt;br /&gt;
&lt;br /&gt;
== Packages and Repos ==&lt;br /&gt;
The package in the MeeGo OBS server for this project is [http://build.meego.com/package/show?package=meego-compliance-tools&amp;amp;project=devel:tools:building devel:tools:building/meego-compliance-tools]. And all the rpm and deb packages for release can be generated by the OBS server. The following Linux distributions are supported:&lt;br /&gt;
&lt;br /&gt;
* Debian 5.0&lt;br /&gt;
* xUbuntu 9.10, 10.04, 10.10&lt;br /&gt;
* Fedora 11, 12, 13&lt;br /&gt;
* openSUSE 11.1, 11.2, 11.3&lt;br /&gt;
* MeeGo 1.0, Trunk (1.2)&lt;br /&gt;
&lt;br /&gt;
The corresponding software repos can be used to install the tools conveniently. Whenever the feature and quality of code are stable enough, the packages and repos will be published at repo.meego.com.&lt;br /&gt;
For rpm packaging ditros, there are three packages available:&lt;br /&gt;
* meego-compliance-tools (common data, will be installed automatically as the dependency of the two packages below)&lt;br /&gt;
* meego-dist-compliance-tools (for MeeGo distro compliance checking)&lt;br /&gt;
* meego-app-compliance-tools. (for MeeGo application compliance checking)&lt;br /&gt;
&lt;br /&gt;
== Source Code ==&lt;br /&gt;
The tools can also be installed by source code. After fetching the code, under the code directory, run:&lt;br /&gt;
  $ [sudo] make install&lt;br /&gt;
&lt;br /&gt;
The source code is hosted at:&lt;br /&gt;
  [http://meego.gitorious.org/meego-developer-tools/meego-compliance-tools meego-compliance-tools@gitorious.org]&lt;br /&gt;
&lt;br /&gt;
== MIC2 ==&lt;br /&gt;
To prepare the images used in compliance tools, you need [[Image_Creation|MIC2]] with new features (version 0.22.0 or later).&lt;br /&gt;
&lt;br /&gt;
=  Features =&lt;br /&gt;
== dist-compliance-tool ==&lt;br /&gt;
It executes compliance checking for MeeGo distributions. The following features are supported:&lt;br /&gt;
* Binary pkg comparison:&lt;br /&gt;
** Exist in target image?&lt;br /&gt;
** Version matches the requirement?&lt;br /&gt;
*** flexible version checking: support rules with comparison operators like &amp;quot;&amp;gt;=&amp;quot; in core pkg list&lt;br /&gt;
* Content in source rpm comparison:&lt;br /&gt;
** This step will be skipped if binary rpm checking fails&lt;br /&gt;
** Spec filename&lt;br /&gt;
** Spec content&lt;br /&gt;
** Sources and md5sum&lt;br /&gt;
** Patches and the content&lt;br /&gt;
&lt;br /&gt;
== app-compliance-tool ==&lt;br /&gt;
For compliance checking for MeeGo applications, the following features are supported:&lt;br /&gt;
* check if all dependent packages exist in core package list&lt;br /&gt;
* check if the target package can be install in the minimal image&lt;br /&gt;
* verify the installation location of the application&lt;br /&gt;
* verify the minimal requirement of the desktop file and icon for the application&lt;br /&gt;
&lt;br /&gt;
= Usage =&lt;br /&gt;
== Images Prepare ==&lt;br /&gt;
Before using the tools, the reference image need to be created by using MIC2 (version 0.22.0 or later):&lt;br /&gt;
 $ sudo mic-image-creator --run-mode=0 --cache=mycachedir --format=fs  --config=&amp;lt;ks file&amp;gt; --package=tar.bz2 --include-source&lt;br /&gt;
The sample ks file can be downloaded at:&lt;br /&gt;
  [[media:Meego-minimal-compliance-1.0.99.1.ks]]&lt;br /&gt;
The sample core list file can be downloaded at:&lt;br /&gt;
  [[media:Core-list-1.0.99.1‎]]&lt;br /&gt;
And the ks file and core list should be synced with and conform to the latest [[Quality/Compliance|MeeGo compliance spec]].&lt;br /&gt;
&lt;br /&gt;
To try the dist compliance check tool (dist_compliance.sh), please prepare a target image as the input. The target image can be generated by using the same method as the above.&lt;br /&gt;
&lt;br /&gt;
== Devices Compliance Check ==&lt;br /&gt;
The executable script &amp;quot;dist_complianc.sh&amp;quot; is for checking compliance of MeeGo devices, or distributions.&lt;br /&gt;
&lt;br /&gt;
        Usage: dist_compliance [-h] [-p pkglist_file] -r reference_img_bz2 -t target_img_bz2&lt;br /&gt;
        Options:&lt;br /&gt;
        -p pkglist_file&lt;br /&gt;
           the file which contain the package list, this option is optional&lt;br /&gt;
           If the option -p is not provided, will take all the packages in the reference image&lt;br /&gt;
        -r reference_img_bz2&lt;br /&gt;
           bz2 format image, the minimal compliance image&lt;br /&gt;
        -t target_img_bz2&lt;br /&gt;
           bz2 format image, the target image to be scaned&lt;br /&gt;
        -h show help usage.&lt;br /&gt;
&lt;br /&gt;
== Apps Compliance Check ==&lt;br /&gt;
The executable script &amp;quot;app_compliance.sh&amp;quot; is for applications compliance checking.&lt;br /&gt;
&lt;br /&gt;
        Usage: app_compliance -p pkg_file -t reference_img_bz2 -c pkglist_file&lt;br /&gt;
        Options:&lt;br /&gt;
        -p pkgfile of the app which to be tested&lt;br /&gt;
        -t reference_img_bz2 which is the image to install the package.&lt;br /&gt;
        -c the core package list in minimal image&lt;br /&gt;
&lt;br /&gt;
= Result Format =&lt;br /&gt;
Currently, the output of checking tools will be store in HTML files.&lt;br /&gt;
Screen capture of sample distribution report:&lt;br /&gt;
[[File:DistSummaryReport.png|none|600px|Sample Report]]&lt;br /&gt;
&lt;br /&gt;
= Bug Reoprt =&lt;br /&gt;
&lt;br /&gt;
If problems were found in compliance tools, please file bugs in bugs.meego.com.&lt;br /&gt;
The corresponding section is: &amp;quot;Development Tools/Tools&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
= TODO =&lt;br /&gt;
&lt;br /&gt;
* re-implement shell scripts with python&lt;br /&gt;
* add checking for contents of binary packages&lt;br /&gt;
* architecture re-design and code update&lt;br /&gt;
* use new image format with separated src.rpm pack&lt;br /&gt;
* web UI&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/File:Meego-minimal-compliance-1.0.99.1.ks</id>
		<title>File:Meego-minimal-compliance-1.0.99.1.ks</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/File:Meego-minimal-compliance-1.0.99.1.ks"/>
				<updated>2010-10-22T10:07:07Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: Meego-minimal-compliance-1.0.99.1.ks&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Meego-minimal-compliance-1.0.99.1.ks&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/File:Core-list-1.0.99.1</id>
		<title>File:Core-list-1.0.99.1</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/File:Core-list-1.0.99.1"/>
				<updated>2010-10-22T10:04:15Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: Core-list-1.0.99.1&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Core-list-1.0.99.1&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/File:DistSummaryReport.png</id>
		<title>File:DistSummaryReport.png</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/File:DistSummaryReport.png"/>
				<updated>2010-10-22T09:55:40Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: Sample of dist compliance checking report&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Sample of dist compliance checking report&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Quality/Compliance</id>
		<title>Quality/Compliance</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Quality/Compliance"/>
				<updated>2010-10-22T09:06:15Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= MeeGo Compliance =&lt;br /&gt;
&lt;br /&gt;
The MeeGo compliance program is designed to make sure things stay compatible, such that the devices supporting a particular MeeGo version can run the same software, and so that app developers know how to build software which will run across the family.    Simply put, we want to make it possible for an application developer to write a MeeGo compliant application once and run it on any MeeGo compliant device.&lt;br /&gt;
&lt;br /&gt;
MeeGo compliance addresses two categories of compliance:  MeeGo compliant applications and MeeGo compliant devices / software products (which will be referred to simply as &amp;quot;devices&amp;quot;). In both cases,  the use of the MeeGo brand will be granted based on being compliant.  Following is an overview of the approach for each of these categories.&lt;br /&gt;
&lt;br /&gt;
==MeeGo Compliant Device Overview==&lt;br /&gt;
&lt;br /&gt;
For MeeGo compliant devices, we're taking a stack-based compliance approach, meaning that all MeeGo devices must use the same core software stack.  Referring to the MeeGo architecture diagram, this core software stack is the MeeGo OS base layer plus the MeeGo OS Middleware layer.&lt;br /&gt;
&lt;br /&gt;
In addition to a sharing the same core software stack, MeeGo compliance will have profiles for each device category (Netbook, Handset, and so on).  A profile specifies additional required components for the profile (e.g. providing device category APIs), minimum hardware requirements and minimum hardware component requirements (such as cellular modem in the handset profile).&lt;br /&gt;
&lt;br /&gt;
It's important to note that the device profiles won't require the inclusion of a complete user experience - but rather the UI framework providing core user interaction and APIs. &lt;br /&gt;
&lt;br /&gt;
A MeeGo compliant device would be compliant to the MeeGo core software stack definition and one (or more) device category profiles.&lt;br /&gt;
&lt;br /&gt;
==MeeGo Compliant Application Overview==&lt;br /&gt;
&lt;br /&gt;
Given that definition of compliance for devices / software products, MeeGo compliance for applications will verify that an application's external dependencies are satisfied by a MeeGo compliant device (in other words, that any libraries or other dependencies of the application are provided within the core software stack and target device profile)&lt;br /&gt;
&lt;br /&gt;
An application can be written to be dependent only on the MeeGo core software stack - in which case it would run on any MeeGo compliant device.  However, applications with UI would typically target a specific device profile - so for example an application could be MeeGo Handset Compliant - meaning that it would run on any device compliant with the MeeGo Handset profile.&lt;br /&gt;
&lt;br /&gt;
==More Detail on Stack Based Compliance==&lt;br /&gt;
&lt;br /&gt;
Stack-based compliance means that a compliant device / software product must use the MeeGo package set without re-packaging - including the MeeGo version of RPM and the MeeGo package names.&lt;br /&gt;
&lt;br /&gt;
Compliance requires the use of the MeeGo source packages for required components, and that any applied patches (e.g. to fix bugs found in the field) must not effect API, ABI, or defined functionality of interfaces.  &lt;br /&gt;
&lt;br /&gt;
Additional packages (beyond those required by compliance) may be added as long as they don't override MeeGo packages or provide functions with the same namespace of MeeGo APIs.  Of course there will also be additional packages and components required to adapt MeeGo to run on a specific hardware platform (we call this &amp;quot;Hardware Adaptation Software&amp;quot; in MeeGo) - the compliance specification will call out any specific packages or components that may vary based on hardware capabilities.&lt;br /&gt;
&lt;br /&gt;
A core part of the program is the Compliance Specification, which describes the rules and requirements for complying.  There's more to the program (trademark licensing, application process, etc.) which will be added later.&lt;br /&gt;
&lt;br /&gt;
== Specification ==&lt;br /&gt;
&lt;br /&gt;
Current draft:&lt;br /&gt;
&lt;br /&gt;
* [http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.0.99.1.pdf Spec 1.0.99.1]&lt;br /&gt;
&lt;br /&gt;
Here's an initial draft of the specification for public comment. This is intended to match the MeeGo 1.1 release, so it uses a similar numbering scheme.&lt;br /&gt;
&lt;br /&gt;
* [http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.0.80.8.pdf Spec 1.0.80.8]&lt;br /&gt;
&lt;br /&gt;
For now, comments to the meego-dev mailing list, until we get kicked off!&lt;br /&gt;
&lt;br /&gt;
== Compliance Tools ==&lt;br /&gt;
&lt;br /&gt;
Compliance tools are used to check MeeGo compliance for MeeGo Distributions or MeeGo Applications. The compliance reference input is the MeeGo core package/file list and a minimal MeeGo reference image created by MIC2, which will contain all the required core packages, as well as src rpms.&lt;br /&gt;
&lt;br /&gt;
For MeeGo distribution compliance checking, the input needs to include the OS image and the src.rpms for all the packages. And for MeeGo Application compliance checking, the input is the application rpm file.&lt;br /&gt;
&lt;br /&gt;
See [[Quality/ComplianceTools|ComplianceTools]] for details.&lt;br /&gt;
&lt;br /&gt;
== Schedule MeeGo 1.1 Compliance ==&lt;br /&gt;
&lt;br /&gt;
* Preliminary compliance package list (i.e. the minimum set of required on-device packages) - week of September 20&lt;br /&gt;
* Next Rev of compliance spec including profiles - week of September 27&lt;br /&gt;
* First version of compliance tools for distribution / device - week of October 4th&lt;br /&gt;
* First version of compliance tools for applications - week of October 11th&lt;br /&gt;
* Final compliance package list and spec for 1.1 release, and tools updates as needed - with the MeeGo 1.1 release end of October&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Packaging/Guidelines</id>
		<title>Packaging/Guidelines</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Packaging/Guidelines"/>
				<updated>2010-04-28T07:49:55Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: /* Writing a package from scratch */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Packaging Guidelines =&lt;br /&gt;
&lt;br /&gt;
Guidelines below were adapted for MeeGo from Moblin, OpenSUSE, Fedora and other distributions.&lt;br /&gt;
&lt;br /&gt;
== Package Naming ==&lt;br /&gt;
* Dash '-' must be used as the delimiter for name parts. &lt;br /&gt;
* Do NOT use an underscore '_', a plus '+', or a period '.' as a delimiter. &lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
== Version and Release ==&lt;br /&gt;
&lt;br /&gt;
=== Version ===&lt;br /&gt;
The Version field in the spec file is where you should put the current version of the software being packaged. &lt;br /&gt;
There are four cases where the version contains non-numeric characters:&lt;br /&gt;
&lt;br /&gt;
* Pre-release packages: Packages released as &amp;quot;pre-release&amp;quot; versions, prior to a &amp;quot;final&amp;quot; version. Example tags include &amp;quot;alpha&amp;quot;, &amp;quot;beta&amp;quot;, &amp;quot;rc&amp;quot;, &amp;quot;cvs&amp;quot;, &amp;quot;git&amp;quot;.&lt;br /&gt;
* Post-release packages: Packages released after a &amp;quot;final&amp;quot; version. These packages contain the same numeric version as the &amp;quot;final&amp;quot; version, but have an additional non-numeric identifier.&lt;br /&gt;
* Snapshot packages: Packages built from SCM snapshots. These packages could be either &amp;quot;pre&amp;quot; or &amp;quot;post&amp;quot; release packages. &lt;br /&gt;
&lt;br /&gt;
=== Release ===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
There is no need for the %{dist} macro in the release field. This is also handled directly by the build system.&lt;br /&gt;
&lt;br /&gt;
The release number is set to zero with any version update. It is increased by one with any change in the package.&lt;br /&gt;
&lt;br /&gt;
== Tags ==&lt;br /&gt;
*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 &amp;lt;code&amp;gt;%packager&amp;lt;/code&amp;gt; in your &amp;lt;code&amp;gt;~/.rpmmacros&amp;lt;/code&amp;gt; instead.&lt;br /&gt;
*The ''Vendor'' tag should not be used. It is set automatically by the build system.&lt;br /&gt;
&lt;br /&gt;
*Usually, the ''Pre&amp;lt;code&amp;gt;&amp;lt;/code&amp;gt;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] .&lt;br /&gt;
* 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.  &lt;br /&gt;
=== Summary Tag ===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 &amp;quot;Web Browser&amp;quot; summarize any web browser, but using additional adjectives (like minimalistic, complex, GNOME, KDE, text-based, fast, or author's) helps characterize a specific package.&lt;br /&gt;
&lt;br /&gt;
The RPM spec file contains only the English version to keep the RPM database small.&lt;br /&gt;
&lt;br /&gt;
*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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Group Tag ===&lt;br /&gt;
&lt;br /&gt;
Valid RPM Groups are:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Amusements/Games&lt;br /&gt;
Amusements/Graphics&lt;br /&gt;
Applications/Archiving&lt;br /&gt;
Applications/Communications&lt;br /&gt;
Applications/Databases&lt;br /&gt;
Applications/Editors&lt;br /&gt;
Applications/Emulators&lt;br /&gt;
Applications/Engineering&lt;br /&gt;
Applications/File&lt;br /&gt;
Applications/Internet&lt;br /&gt;
Applications/Multimedia&lt;br /&gt;
Applications/Productivity&lt;br /&gt;
Applications/Publishing&lt;br /&gt;
Applications/System&lt;br /&gt;
Applications/Text&lt;br /&gt;
Development/Debuggers&lt;br /&gt;
Development/Languages&lt;br /&gt;
Development/Libraries&lt;br /&gt;
Development/System&lt;br /&gt;
Development/Tools&lt;br /&gt;
Documentation&lt;br /&gt;
System/Boot&lt;br /&gt;
System/Console&lt;br /&gt;
System/I18n/Chinese&lt;br /&gt;
System/I18n/Japanese&lt;br /&gt;
System/I18n/Korean&lt;br /&gt;
System/Packages&lt;br /&gt;
System/Base&lt;br /&gt;
System/Daemons&lt;br /&gt;
System/Kernel&lt;br /&gt;
System/Libraries&lt;br /&gt;
System/Shells&lt;br /&gt;
System/X11&lt;br /&gt;
System/X11/Fonts&lt;br /&gt;
System/X11/Icons&lt;br /&gt;
System/GUI/XFCE&lt;br /&gt;
System/GUI/Other&lt;br /&gt;
System/GUI/GNOME&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== BuildRoot tag ===&lt;br /&gt;
The ''BuildRoot'' value MUST be below &amp;lt;code&amp;gt;%{_tmppath}/&amp;lt;/code&amp;gt; and MUST contain at least &amp;lt;code&amp;gt;%{name}&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;%{version}&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;%{release}&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The ''recommended'' values for the ''BuildRoot'' tag are (in descending order of preference) :&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
%{_tmppath}/%{name}-%{version}-%{release}-root&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== PreReq ===&lt;br /&gt;
&lt;br /&gt;
Packages should not use the PreReq tag. Once upon a time, in dependency loops PreReq used to &amp;quot;win&amp;quot; over the conventional Requires when RPM determined the installation order in a transaction. This is no longer the case.&lt;br /&gt;
&lt;br /&gt;
=== Explicit Requires ===&lt;br /&gt;
Packages must not contain explicit ''Requires'' on libraries except when absolutely &lt;br /&gt;
necessary. When explicit library ''Requires'' are necessary, there should be a spec file comment justifying it.&lt;br /&gt;
&lt;br /&gt;
We generally rely on rpmbuild to automatically add dependencies on library SONAMEs. &lt;br /&gt;
Modern package management tools are capable of resolving such dependencies to determine &lt;br /&gt;
the required packages. Explicit dependencies on specific package names may aid the &lt;br /&gt;
inexperienced user, who attempts at installing RPM packages manually, however, history &lt;br /&gt;
has shown that such dependencies add confusion when library/files are moved from one &lt;br /&gt;
package to another, when packages get renamed, when one out of multiple alternative &lt;br /&gt;
packages would suffice, and when versioned explicit dependencies become out-of-date and &lt;br /&gt;
inaccurate. Additionally, in some cases, old explicit dependencies on package names &lt;br /&gt;
require unnecessary updates/rebuilds. &lt;br /&gt;
&lt;br /&gt;
Exemplary rationale for a versioned explicit dependency:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  # The automatic dependency on libfubar.so.1 is insufficient,&lt;br /&gt;
  # as we strictly need at least the release that fixes two segfaults.&lt;br /&gt;
  Requires: libfubar &amp;gt;= 0:1.2.3-7&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Packagers should revisit an explicit dependency as appropriate to avoid &lt;br /&gt;
it becoming inaccurate and superfluous.&lt;br /&gt;
&lt;br /&gt;
=== BuildRequires ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Before adding Build&amp;lt;code&amp;gt;&amp;lt;/code&amp;gt;Requires to any package, please be comfortable with [[#Requires|  Requires]] .&lt;br /&gt;
&lt;br /&gt;
=== Patches ===&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
* Authors' names&lt;br /&gt;
* Detailed description of the fixed problem&lt;br /&gt;
* URL of the original source of the patch if any&lt;br /&gt;
&lt;br /&gt;
The name of a patch file consists of:&lt;br /&gt;
&lt;br /&gt;
* The name and version of the source tarball from which the patched file is derived&lt;br /&gt;
* Some words that characterize the patch content&lt;br /&gt;
* The filename suffix &amp;lt;code class=&amp;quot;filename&amp;quot;&amp;gt;.patch&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Patches are in the unified format (&amp;lt;span&amp;gt;'''diff -u'''&amp;lt;/span&amp;gt;) and should be applied with 1 strip level in the spec file (&amp;lt;span&amp;gt;'''%patch -p1'''&amp;lt;/span&amp;gt;). The only exceptions are the patches obtained from an another primary source site. The original name, suffix, and format is preserved in this case.&lt;br /&gt;
&lt;br /&gt;
Each patch should be compressed with &amp;lt;span&amp;gt;'''bzip2'''&amp;lt;/span&amp;gt; if its size is greater than 100kB. The macros &amp;lt;code class=&amp;quot;systemitem&amp;quot;&amp;gt;%name&amp;lt;/code&amp;gt; and &amp;lt;code class=&amp;quot;systemitem&amp;quot;&amp;gt;%version&amp;lt;/code&amp;gt; should be used whenever possible.&lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
 Source:   %{name}-%{version}.tar.bz2&lt;br /&gt;
 Patch0:   %{name}-%{version}-autoconf.patch&lt;br /&gt;
 Patch1:   %{name}-%{version}-gcc31.patch&lt;br /&gt;
&lt;br /&gt;
For the patches to be applied, the patches should be mentioned under %setup. For the above example, this could be done as&lt;br /&gt;
&lt;br /&gt;
 %setup -q&lt;br /&gt;
 %patch0 -p1&lt;br /&gt;
 %patch1 -p1&lt;br /&gt;
&lt;br /&gt;
== Writing a package from scratch ==&lt;br /&gt;
&lt;br /&gt;
See [[Spectacle]]&lt;br /&gt;
&lt;br /&gt;
== Modifying existing Packages ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
In particular, you should&lt;br /&gt;
&lt;br /&gt;
* verify any sources and patches and remove patches or sources that:&lt;br /&gt;
** are related to platforms we do not support (example: sparc, ia64, ppc, ...)&lt;br /&gt;
** Implement features we do not support (example: selinux)&lt;br /&gt;
** Read every patch and understand what it does, if it is needed, put an explanation in the header justifying why the patch is needed.&lt;br /&gt;
* verify that the license stated in the spec file matches the actual license of the software,&lt;br /&gt;
* skim the summary and description for typos and oddities (see Summary and description ),&lt;br /&gt;
* make sure that the correct build root is used,&lt;br /&gt;
* ensure that macro usage is consistent and that the macros are available in MeeGo (see Macros ). &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Changelogs ==&lt;br /&gt;
&lt;br /&gt;
This section describes the MeeGo policy for RPM changelogs. (Original changelogs included in the original source are not affected by this policy.) &lt;br /&gt;
&lt;br /&gt;
Please consider that a &amp;quot;normal end user with some technical skills&amp;quot; should be able to read and understand an RPM changelog. Changelog entries have to be in chronological order. Newer change log entries are listed above older entries, with the first entry being the most recent. &lt;br /&gt;
&lt;br /&gt;
=== General information ===&lt;br /&gt;
&lt;br /&gt;
* MeeGo uses a separate file for package changes. This file is called like the spec file, but has *.changes instead of *.spec as ending remarkably similar to a debian changes file.&lt;br /&gt;
* Entries in the changes file have the following structure:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Tue Apr 22 20:54:26 CEST 2009 - your@email.com&lt;br /&gt;
&lt;br /&gt;
-&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In short, the changes file is identical in format and purpose to debian's changes file. &lt;br /&gt;
&lt;br /&gt;
=== Bug Numbers in the change log ===&lt;br /&gt;
&lt;br /&gt;
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/. Adding an entry with bugzilla number to the changelog should result in a short description of the bug-summary and the bug number. For example:&lt;br /&gt;
 - Removed invalid desktop Category &amp;quot;Application&amp;quot; (MB#4654).&lt;br /&gt;
 - Symlink icon to pixmaps dir (MB#2108)&lt;br /&gt;
 - Added gnome-ui-properties to control-center (MB#1960).&lt;br /&gt;
&lt;br /&gt;
=== CVE numbers in change log ===&lt;br /&gt;
&lt;br /&gt;
Same as for bugzilla numbers: Add a short description (normally the CVE summary should be enough), the Bugzilla and the CVE number to the changelog entry. Examples:&lt;br /&gt;
 - Add gdk-pixbuf-226710.patch (MB#226710, and CVE-2007-0010).&lt;br /&gt;
 - More XPM fixes: CVE-2005-2975 xpm too many colors DoS (MB#129642)&lt;br /&gt;
 - fix ~/.dmrc symlink attack (MB#180704, CVE-2006-2449)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Spec File changes ===&lt;br /&gt;
Be as precise as possible! This is especially important if you remove something from the spec file. &lt;br /&gt;
&lt;br /&gt;
* Removing original source code must be declared in spec file with a comment (&amp;quot;useful for FreeBSD only&amp;quot; for example) - not necessary to repeat the comment in specfile.&lt;br /&gt;
* Extra commands (for example during %install) can be illustrated with a short comment in spec file&lt;br /&gt;
* Adding/Removing packages from Requires/Provides must be described in the changelog&lt;br /&gt;
&lt;br /&gt;
=== Source Code changes ===&lt;br /&gt;
&lt;br /&gt;
Document the most important changes but limit verbosity.&lt;br /&gt;
&lt;br /&gt;
* 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.&lt;br /&gt;
* arrange the original changes behind the version update information. Example:&lt;br /&gt;
  - Update to 1.3.2:&lt;br /&gt;
    + fixes memory leak in import function&lt;br /&gt;
    + new API command: unlock_client()&lt;br /&gt;
    + the following bugs are closed by this new upstream release:&lt;br /&gt;
    ++ ............ [MGN:332]&lt;br /&gt;
    ++ .............[MGN:337]&lt;br /&gt;
  - split of devel package&lt;br /&gt;
* If upstream does not provide a meaningful change log, then only do best effort. Don't waste too much time over it.&lt;br /&gt;
* 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 &amp;quot;updated translation&amp;quot; or &amp;quot;several bug fixes&amp;quot; even that can be sufficient for a changelog entry (unless these bug fixes contain something you find worth mentioning).&lt;br /&gt;
&lt;br /&gt;
[[Category:Packaging]]&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	<entry>
		<id>http://wiki.meego.com/Spectacle</id>
		<title>Spectacle</title>
		<link rel="alternate" type="text/html" href="http://wiki.meego.com/Spectacle"/>
				<updated>2010-04-28T07:29:41Z</updated>
		
		<summary type="html">&lt;p&gt;Jfding: Created page with '== 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…'&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Spectacle is the toolset for packaging maintenance of MeeGo, including the tool&lt;br /&gt;
to generate spec files from metadata file in YAML format, and tools to convert  &lt;br /&gt;
spec files or spec-builder's ini files to YAML format.                          &lt;br /&gt;
&lt;br /&gt;
For spectacle managed packages, all generic packaging information will be stored&lt;br /&gt;
in the YAML file, and it also allows maintaining customizations in the spec file&lt;br /&gt;
directly with special enclosure tags.                                           &lt;br /&gt;
&lt;br /&gt;
Three separated tools will be installed:&lt;br /&gt;
&lt;br /&gt;
* specify: the tool to generate or to update spec file, based on YAML&lt;br /&gt;
* ini2spectacle: the tool to convert spec-builder .ini to YAML and new spec file&lt;br /&gt;
* spec2spectacle: the tool to convert original spec to YAML and new spec file&lt;br /&gt;
&lt;br /&gt;
== Installation ==&lt;br /&gt;
=== Instruction ===&lt;br /&gt;
Several methods available for spectacle installation:&lt;br /&gt;
&lt;br /&gt;
* rpm/deb packages for several supported Linux distributions&lt;br /&gt;
  From [http://repo.meego.com/tools/repo/ MeeGo Repos], repo urls can be found for:&lt;br /&gt;
    * MeeGo&lt;br /&gt;
    * Fedora 10,11,12&lt;br /&gt;
    * openSUSE(s)    &lt;br /&gt;
    * xUbuntu 8.10/9.04/9.10&lt;br /&gt;
    * Debian 5.0            &lt;br /&gt;
&lt;br /&gt;
* Download the latest source package, and install it by ``make install``&lt;br /&gt;
  The latest code in git tree can be accessed at:&lt;br /&gt;
  [git://gitorious.org/meego-developer-tools/spectacle.git]&lt;br /&gt;
&lt;br /&gt;
=== Requirements ===&lt;br /&gt;
* python 2.x, above 2.5&lt;br /&gt;
* PyYAML, the python module for YAML parsing&lt;br /&gt;
* cheetah, one popular templating system for python&amp;lt;br&amp;gt;&lt;br /&gt;
    In many linux distributions, the package may be named as python-cheetah.&lt;/div&gt;</summary>
		<author><name>Jfding</name></author>	</entry>

	</feed>