2011年6月2日木曜日

MeeGo Porting Guide なんちゃって翻訳(その2) 相変わらず途中まで

はい、前回のMeeGo Porting Guide翻訳のパート2です。

前回の翻訳部分は概要の後、ビルドのツールについての説明に入っていました。

思いっきり要約すると、「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

2011年6月1日水曜日

MeeGo Porting Guide なんちゃってGoogle翻訳(途中)

今のGoogle翻訳は使えないとか思っている隠者です。出てくる翻訳結果がねぇ・・・。

ただ、Google翻訳は、自力で訂正を登録できるようなので、もしかしたら頻繁に修正していけば、使い物になるのうになるのかもしれません。というわけで、MeeGo Porting GuideをGoogle翻訳を使いながらちょこちょこ翻訳を手直ししつつ、多少は読める所までを目標に翻訳はじめてみました。です・ます調とである調が混在してますけど、とりあえず半自動翻訳なのでお許し下さい(注:どうしてもうまく文節を認識してもらえないものは分割して翻訳しています)。

本当は meego.jp のwikiにいれたいのだけど、いまいちページの構成とかどう階層付けしたらいいかとかわからないんですよねぇ・・・・。

イントロダクション


MeeGo Porting Guide(MPG)の目標は、(新しい)ハードウェアの上でMeeGo OSを実行し、最終的にMeeGo OSをベースに製品を作成したい人のための貴重な情報と説明を提供することです。 MPGは、移植プロセス、ツール、およびその他の関連する背景情報の概要から始め、移植が実際に個々の技術的/機能的領域において意味することの説明に移ります。

移植ガイドは、厳密に特定のMeeGo OSバージョンまたはデバイスのカテゴリに関連付けていません。代わりに異なるデバイスの種類をカバーするだけでなく、新しいMeeGo OSのバージョンで導入された変更に追従し十分に汎用的であることを目指しています。

異なる技術分野での詳細移植情報は、各MeeGoアーキテクチャに依存しています。いくつかのケースでは、このアーキテクチャでまだ未決定の可能性があり、これについては該当するセクションに記載されています。



フィードバック

これらのページへ投稿はオープンです。すべてのMeeGoコミュニティのメンバーはいつでもこれらのページを向上させる自由があります。また、MeeGo移植メーリングリストにフィードバックをすることができます。

一般的な移植情報/ガイドライン

MeeGo Compliance

おそらく、MPGに関連する背景情報の最も重要な部分は、MeeGoコンプライアンス要件です。MeeGoに準拠することを意図されているデバイスは該当するデバイスのカテゴリのMeeGoコンプライアンス仕様(仕様の最初のバージョンは2010年10月に使用できるようになっている)に記載されている要件を満たす必要があります。要するに、MeeGo準拠のデバイスは以下を満たす必要があります:
  • 該当するデバイスカテゴリの最小ハードウェア性能とコンポーネント要件を満たす
  • MeeGoコアOSを構成するすべてのSWのコンポーネントを含める
  • 該当するデバイスカテゴリにおいて存在するデバイスの必要な、追加ソフトウェアコンポーネントを含む
  • MeeGo由来コンポーネントのいずれのAPI/ ABIも壊さない
  • MeeGo ソフトウェア包装規則に従う
コンプライアンス規則はMeeGo OSそのものとMeeGoアプリケーションが異なる環境(使用される命令セットコンパイラバージョン、コンパイラオプションなど)でコンパイルされる方法に関してCPUアーキテクチャ固有の要件を指定します。

デバイスの製造元は、MeeGoコンプライアンスを壊さしない限り、それらのデバイスの追加機能をハードウェアコンポーネントとSWのコンポーネントを含むことができる。ベンダーはパッチがMeeGoコンプライアンスを壊さない場合、MeeGo OSのコンポーネントにパッチを当てる事ができる。それら該当するソフトウェアライセンスにより設定されている規則に準拠する限り、デバイスベンダー独自のソフトウェアコンポーネントは、オープンソースやクローズドソースののコンポーネントにすることができます。

MeeGo Porting Guideの観点から、コンプライアンスの要件は-存在する必要のあるソフトウェアコンポーネントとハードウェアコンポーネントを定義している-デバイスのベンダで移植するための必要な作業最小セットとMeeGo OS側からの関連するソフトウェアコンポーネントを効果的に定義しています。

移植プロセスとツール

概要

ベンダーのデバイスが上記で定義したMeeGoに準拠している場合に限り、彼らが、デバイスのためのSWをどのようにビルドするのかは基本的にはベンダー次第です。ベンダーは、彼らの所有するビルドのマシンやMeeGoでも使用されるOBSビルドシステムをセットアップして使用することができます。ベンダーのビルドシステムが、何であるかに関係なく、それはMeeGoビルドインフラストラクチャと統合するするには、少なくともビルドのためにMeeGoソースパッケージを取得するだけでなく、MeeGoコンポーネントがMeeGoビルドシステムで構築される同じ方法(同じコンパイラおよびコンパイラオプションを使用してなど)で、それぞれのビルドをする必要があります。いずれにせよ、MeeGoにおいては、任意のハードウェアまたはソフトウェアのベンダーが、効率的なSWの作成に使用できるオープンなツールセットを提供し使用しています。MeeGoと同じツールセットを使用することでMeeGoビルドインフラストラクチャとベンダー独自のビルドシステムを統合する最も簡単な方法を提供できるでしょう。

MeeGoビルドインフラストラクチャおよびツールセットの主要な成分:

  • MeeGo Gitorious
    様々なMeeGo固有SWコンポーネントとツールのソースファイルのバージョン管理システム
  • MeeGo OBS
    ソースからMeeGoパッケージ(RPM)を構築するために使用されているビルドシステム
  • MeeGo Repository
    ビルドされたMeeGoリリース、すなわちMeeGoパッケージとイメージが格納されている場所
  • MeeGo Image Creator
    ハードウェアにフラッシュ/インストールできるMeeGoイメージをビルドするために使用するツール
  • MeeGo release tools
    repo.meego.comの下でMeeGoリリースの作成に使用されているBOSSとREVSのようなのツール

関連情報を参照するには、ビルドインフラストラクチャリリースインフラストラクチャおよびリリースエンジニアリングを参照してください。

MeeGoの移植プロセスの別の概要については、ハードウェアの有効化プロセスを参照してください。