前回の翻訳部分は概要の後、ビルドのツールについての説明に入っていました。
思いっきり要約すると、「MeeGoのコンプライアンスに従い、ABIやAPIを壊すことがないのであれば、HWベンダは独自のソフトのために独自のビルドマシンを使おうと、MeeGoのビルドシステムを使おうとかまわない。ただ、そのためには、MeeGoをビルドしているシステムと同じツールセットを使うことになるだろう」ということで、MeeGoのビルドに使われているツールが列挙されていました。
というわけで、前回に引き続き途中までGoogle翻訳で翻訳を続けていたのですが・・・twitterで、Google Translator Toolkitでないと普通の翻訳は覚えてくれないよ・・・と指摘を受けまして、がっかりです。無駄に浪費時間を返せ！と叫びたい気分です。
というわけで、途中からはかなり投げやりに適当翻訳を行ってますので、ご容赦ください。
：
ベンダ独自のOBSしたがって、結局のところ、MeeGo OSを実行する実際の製品を作成する場合、ベンダーは独自のOBSビルドシステムを設定する事にになるかもしれません。独自のOBSシステムは新しいハードウェア上でテストするためのMeeGo OSの変更とビルドの柔軟な方法を提供するので、初期のハードウェア/製品開発の段階で有益であるかもしれません。ベンダ独自のOBSシステムはMeeGoから示されたパッケージを扱うためや他のソース、例えば、そのベンダーに固有のクローズドソースのパッケージ等、を扱うリンクをMeeGoOBSにリンクできます。このセットアップの概要図を参照してください。
ベンダーの設定：
- 独自のOBSシステムを設定する
OBSシステムの設定に関する手順については、OBS Applicances OpenSUSE OBSのWikiになります。 - 独自のコンポーネントのため独自のOBS 下のプロジェクトを作成する
- MeeGoコンポーネント用に独自のOBSをMeeGoOBS へのリンクする
- 自分のOBSがMeeGoのコンポーネントに試験的なパッチを当てることがあります
Note : 最終的に完成したMeeGoベースの製品でMeeGoのコンポーネントに必要なすべてのパッチはMeeGo.comにプッシュする必要があります。ただし、これはMeeGoコンプライアンス要件および該当するSWライセンスのルールとして満たされている限り絶対に必須要件になるわけではありません。
上流のプロジェクト、MeeGo、製品、およびパッチを参照してください
- OBSで作成されたパッケージからリリースおよびイメージを作成するために必要な機器をセットアップが必要
この機器は、MeeGoで使用されるツールセットをベースにすることができます（上記参照）
MeeGo.comの下での作業
いくつかの新しいハードウェアにMeeGoを移植するのもう一つの方法は、新しいハードウェアは、1つMeeGoリファレンスハードウェアとして受け入れを取得し、MeeGoビルド機構で通常のMeeGoリリース構築サイクルの一部ハードウェアとしてリファレンス用にビルド作成するものです（リリースタイムラインとリリースプロセスを参照してください）。また、この設定ではMeeGoサイドのリファレンスハードウェアのQAサポートを含めることができます（クオリティを参照してください）。この文書の執筆時点で、MeeGoの新規リファレンスハードウェアを得るための実際のプロセスはまだ多少は不明瞭です。いずれにせよ、このモデルはMeeGoで、それらのリファレンスハードウェアをサポートする一般的なMeeGo作業ではベンダーから特に積極的に参加する必要があります。
ベンダーの設定：
- それらのコンポーネントのMeeGo OBS下にあるデバイス/プラットフォーム開発プロジェクトを作成します。オープンソースのコンポーネントは、MeeGoトランクに提出になるでしょう。: 含めるために他のMeeGoコンポーネントのようにテストやレビューを行います。
MeeGo OBSではいくつかのリファレンスHWのMeeGoをビルド含めるためクローズドソースのバイナリコンポーネントを持つことも可能であることに注意してください。これらは、トランク：non-ossのリポジトリに提出されます。repo.meego.com からミラーやホストができないので、通常、ライセンスはコンポーネントが少なくとも再配布可能性を含むようにする必要があります。
- 他のMeeGoコンポーネントへのパッチは、必要に応じてMeeGo.comへをプッシュします（上流のプロジェクト、MeeGo、製品、およびパッチを参照）
- それらのリファレンスHWのイメージを構築するためのMICキックスタートファイルを作成します（または作成をサポートします）
- 必要に応じて、MeeGoのビルドとインフラストラクチャのリリースツールでそれらのリファレンスハードウェアとソフトウェアコンポーネントのサポートを追加サポートします
トライアル
上記のプロセスの代わりに、限定的ですが簡単な"try it out"について以下に記述します。
最初の試み
- まずはあなたのターゲットにもっとも近いすでにビルドされたMeegoのリファレンスのためのrootファイルシステムを入手します。ARMv7の場合、通常N900ハンドセットのイメージで、Atomの場合、Netbookのイメージやハンドセットのイメージになるでしょう。
- あなたのデバイス向けのLinux kernelをビルドしモジュールを/lib/modulesにインストールします。
- rootファイルシステムを起動し、コンフィグレーションに手をいれ、デバイスをとめるようなUXをはずします。
- あなたのポーティング作業について修正したり追加したことを書きとめておいて下さい。
最初のイメージの作成
適切なハードウェアアダプテーションの第二ステップは、あなた自身のイメージをビルドできるようにすることです。この前までの作業がリファレンスデバイスのイメージに基づいているので、手始めにこのイメージを作成することが理にかなっています。MeeGoのイメージは、イメージの内容計画を記述するいわゆる'kickstartファイル'に基づいて構成されます。
- Meego Image Creator tool(MIC)をインストールします
- リファレンスデバイスのイメージを見つけたのと同じディレクトリからkickstartファイル(.ks)をダウンロードします。
- mic-image-creatorを使ってイメージを生成します（should be elaborated）。
- 前のステップで焼きたてほやほやのイメージを試してみる。
あなたが移植した最初の再生イメージをビルドする
- MeeGo kernelをダウンロードし、場合によっては新しいデバイスドライバを含むパッチを適用し、カーネルをビルドします（新チップセットをサポートしたMeeGoカーネルの取得方法の記述を参照)
- Kickstart fileにあなたのカーネルパッケージを含むリポジトリを追加します(to be elaborated)
- Kickstartファイルからリファレンスデバイス固有の部分を取り除きます
- %packagesセクションにあなたのカーネルパッケージについての記述を追加します
- あなたのデバイスに合わせてkickstartファイルの%postセクションに、ビルドしたパッケージやシェルスクリプトの設定を追加変更します。
MeeGoカーネルの新しいチップセットのサポートを入手する
どのようにMeeGoカーネルを動作させ、新しいハードウェアをサポートするかについてのもっと詳細な情報は、How-Toの 新チップセットをサポートしたMeeGoカーネルの取得方法を参照してください。
というわけで、失意のなかでちらほらとがんばったのですが、全部翻訳するには到底おいついていないわけで、今日も途中までということで。
本日twitterで@kimitake さんが見つけてきてくださった過去MLを超大雑把に翻訳すると、meego.comの翻訳については歓迎するけど、どう載せていくかは、meego.jpのような方法が良いんじゃなかろうかといった意見がある様子。
でも、実は、meego.jpはwikiをもってなくて、独自wikiがあるのはmeego-users.jpなんですよね。
このあたりがこうムズムズするところなんですが、MeeGoというのはもともと、もっとオープンにコミュニティーとして作り上げていこうという趣旨もあって、meego.comにアカウントを作ることもそのwikiを編集することも自由のようです。
ところが、日本の場合は、meego.comの日本版のはずのmeego.jpのほかに、meego-users.jpなんてのもあるんですよね。Androidの場合は、新しい方向性やベースの開発はクローズドに行われているし、OHAとユーザー会とが別にできるのはしょうがないのですけど。
meego.jpとmeego-users.jpの立ち位置とか、ユーザーが何をどこまでどうしていけるのか、もう少し明瞭にしてもらわないと動きにくいような気がしています。
# え、ユーザー会で直接言えって？まぁ、そうかもしれないのだけど、隠者はほら、超小心者ですので・・・・orz
