Linux あれこれ

Linux 関連の備忘録です。

「Haiku」にてアプリを日本語化する準備〈H136-1〉

登録日: 2021-10-07 更新日: 2021-10-18

Haiku にて、アプリの日本語化にトライしました。その備忘録です。

-

Haiku ではシステムが書き込み保護されており、直接システムをいじれないので、いつもとは違うアプローチが必要でした。

Linux アプリをHaiku に移植するときに使われる環境を落とし、それを使ってアプリの日本語化にトライしました。 一度作っておくと、欲しいアプリの日本語化、および、アプリの移植にトライできます。

-

今回は、そのアプリの日本語化にトライするための環境づくりです。

USB メモリに「nightly ビルド」の「Haiku R1/beta3」をインストール しました。システムとしては最新です。そこで作業しました。

-

-

使用したPC は「ASUS Chromebox CN60 」で、 プロセッサは第4世代の「Intel Celeron 2955U 」です。

-

(注)リンクを戻るときはブラウザの左上の「←」をクリック

-

-


目次

-

「アプリの移植について」

「作業フォルダ作成の流れ」

「日本語入力のインストール」

「haikuporter ツールをインストール」

「haikuporter ツールを実際に使用」

「Linux から移植されたアプリを確認」

「Haiku 専用に作られたアプリを確認」

「まとめ へ」

-

「目次詳細 へ」

-

-


--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - -

-

Haiku R1/beta3」のデスクトップ

-

立ち上げ時に「ブートスクリーン」が表示されます:

-

「nightly ビルド」のデスクトップ画面:

→「nightly ビルド」は開発版と言えますが、更新の回数が多いので不具合が解消されている可能性があります。

-

「nightly ビルド」のアイコン:

→立ち上げデバイス(ボリューム)には「てんとう虫」マークが付きます。

-

現在使っているデスクトップ画面:

テキストエディタは日本語入力時にインライン変換ができる「Koder」にしました。ブラウザは確実に動く「Otter Browser」です。

-

左側は「Koder」アプリのウィンドウです。英語表示を日本語化(というか日本語化されるように修正)しました。 時々見かけますが、翻訳ファイルがあっても日本語化されていないのはもったいないですね。 メニューを日本語化しただけで、使いやすく感じます。

-

-


--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --

-

現在のシステムのバージョン:

-

2021-10-07 現在:

~> uname -v
hrev55489 Oct  7 2021 06:03:30

-

時々、デスクトップが表示しきれないことがあるので、

もし、立ち上げで背景色のまま、デスクトップが表示されないときは「ココ 」を参照

-

-


--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ---

-

アプリの移植について:

-

1). リモートにあるリポジトリの一覧:

~>  pkgman list-repos
        Haiku
                base-url:  https://eu.hpkg.haiku-os.org/haiku/master/x86_64/current
                identifier: tag:haiku-os.org,2001:repositories/haiku/master/x86_64
                priority:  1
        HaikuPorts
                base-url:  https://eu.hpkg.haiku-os.org/haikuports/master/x86_64/current
                identifier: tag:haikuports.org,2013:repositories/haikuports/master/x86_64
                priority:  1

→「Haiku」はHaiku アプリのリポジトリで、「HaikuPorts」はLinux から移植されたアプリのリポジトリです。 パッケージ化(ビルドしてバイナリ化してまとめた)されたアプリが格納されています。

-

  • 「haikuporter」ツールが使えるようになったことで、Linux から移植されたアプリが増えました。

  • 一般的によく使われているアプリがもっと増えていけば、実際に使えるOS に近づくと思います。

  • Haiku が生き残れるかは、システムの安定性と使えるアプリ次第だろうと思います。

-

2). 今回は、リモートの「HaikuPorts」リポジトリにあるアプリの「ソース」に対してビルドの指示をする「レシピ」ファイルをローカルに置いて作業しました

-

3). すべてのアプリの「レシピ」ファイルと「パッチ」ファイルをごっそりダウンロード

-

4). 一度パッケージ化を実行すると、作業フォルダが削除されずに残ります

作業フォルダが残ることの利点は、システムにインストールされたアプリだけでなく、作業フォルダにあるビルド済みのアプリ(実行ファイル)も、右クリックのときに指定できることです。

システム更新でアプリが上書きされてしまうことがありますが、メニューからは起動できなくなっても、パッケージ化が済んで、実行したことがあれば、右クリックで(実行ファイルの場所が表示されるので)ホームの作業フォルダに置かれたアプリを指定して起動できます。

-

5). Haiku 向けに作られたアプリでの注意点

アプリによっては、Haikuファイルシステムの「BeFS」だけが持つファイル属性 を持たせたものがありました。Ext4Fat32 にファイルをコピーするとその属性は消えます。

なので、Haiku 上でしかビルドできませんし、ソースファイルであっても、使われるツールでチェックされたりするので、ビルド前に指定されたファイル属性を付与して、tar.gz してサイトに置くか、ビルド時にファイル属性を付与するしかけを作る必要があります。

→例えば、Haiku で使われる翻訳ファイルが該当します。翻訳ファイルのバイナリ変換ツールはファイル属性(シグネチャー)をチェックしており、翻訳ファイルに属性がセットされていないと、ビルドの途中でエラーします。

アプリの実行ファイルは埋め込まれたシグネチャーにより、どの翻訳ファイルを使うかを決めており、埋め込みをされた実行ファイルでないと翻訳できません。Haiku 向けアプリでよく使われる、Haiku 独自のしくみです。

-

6). 移植されたアプリでの注意点

移植されているアプリが最新バージョンとは限りません。たぶん、古いバージョンです。 アプリはバージョン指定で移植されています。

それは、バージョンによって依存するパッケージやライブラリが異なるので、「レシピ」ファイルも修正しないとビルドできないからです。アプリによっては、ソースやMakefile の修正も必要になります。つまり、パッチファイルの作成です。

また、実行時に使われるconfig ファイル等が書き込みできない領域に配置されることで、支障が出る場合があります。

→featherpad のヘルプファイルはテキストファイルで、個人的な備忘録として使える機能がありますが、Haiku では書き込みできないので使えません。

-

-


--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----

-

作業フォルダ作成の流れ

-

「Koder-0.5.3」の場合:

-

1). アプリをパッケージ化するコマンドを入力:

> cd ~/Git/haikuports/
> hp koder

エイリアスが登録 されているときに使えるコマンドです。

-

アプリのレシピに、ダウンロードすべきバージョンの.tar.gz が書かれています:

~/Git/haikuports/haiku-apps/koder/koder-0.5.3.recipe の指定:

SOURCE_URI="https://github.com/KapiX/Koder/archive/$portVersion.tar.gz"

-

それが「download」フォルダにダウンロードされます。

その後に「work-0.5.3/sources」に展開され、その展開された「Koder-0.5.3」フォルダにローカルのリポジトリ(.git フォルダ)が作成されます。

ブランチ名は「haikuport」で、タグ名は「ORIGIN」です。

ソースなので個別に手を加えられますし、git で管理されているので、複数のファイルの変更を行っても、差分ファイルの作成が簡単で、パッチファイルを作成しやすくなります。

-

アプリのGitHub からそのままgit clone するのでなく、指定したバージョンのみを.tar.gz でダウンロードして、移植用のローカルのリポジトリを作り直しているところがエライと思います。本家のgit の管理のやり方は色々なので、それに左右されないのはgood です。

-

2). ソースを修正したのであれば、レシピにパッチファイルの定義の行を追加します:

~/Git/haikuports/haiku-apps/koder/koder-0.5.3.recipe の指定:

PATCHES="koder-$portVersion.patchset"

→汎用性のある作りにしてあり、番号は自動で入ります。

-

作成したパッチファイル:
~/Git/haikuports/haiku-apps/koder/patches/koder-0.5.3.patchset

→差分ファイルを元に作成。

-

3). パッチファイルの指定があれば実行され、ソースが書き換えられます

レシピにあるビルドの指定により、ビルドされます。

-

4). ビルドの結果が「~/Git/haikuports/haiku-apps/koder/work-0.5.3/sources/Koder-0.5.3/objects/」フォルダに書き込まれます

→出力先に「objects/」フォルダが指定されているときのみ。

-

5). ビルド後のインストール(リンクとシステムのフォルダの作成と配置)が成功すれば、パッケージファイルが作成されます

~/Git/haikuports/packages/koder-0.5.3-1-x86_64.hpkg

→パッケージ作成の最後に、作成された「場所とパッケージ名」が表示されます。

-

6). パッケージ名を指定してのインストールができます:

> pkgman install ~/Git/haikuports/packages/koder-0.5.3-1-x86_64.hpkg

→システム更新があって上書きされるまでは、メニューからアプリが起動できます。

-

7). インストールしたアプリは、下記にも登録されます:

/boot/system/packages/koder-0.5.3-1-x86_64.hpkg

→通常、アプリがインストールされると、ここに登録されます。

ここに登録されると、システム更新の対象になるため、システム更新があるタイミングで、パッケージ名が同じであれば上書きされます。せっかく日本語化しても元に戻るので、メニューからのアプリの起動は英語になります。

-

8). 上書きされても、作業フォルダを削除しないかぎり、右クリックからアプリを選択して、日本語表示で起動できます

インストールして正常に動いたら、早めにプルリクエストして貢献するか、個人的にパッケージ名を変更してパッケージを作成するか、です。

-

9). アプリをインストールして起動できたら、実際の動作を確認

単にビルドが通っただけで、実際に日本語化されるとは限りません。 ソースや、Makefile などの修正が必要かもしれませんし、locale の設定で変わるかもしれません。

作業ファイルに実際のソースが残っているので、それを使って色々と試行錯誤します。 ここで、Haiku の知識と、プログラミング言語のスキルが問われます。アプリによって使われているプログラミング言語や、使われているライブラリも違うので、勉強になります。うまくすれば、それらはさわらなくて済むかもしれません。

-

修正が済んだら「git diff」で差分を作成、「patches/koder-0.5.3.patchset」に反映。 「koder-0.5.3.recipe」の修正が必要なときもあります。

-

「download」フォルダと「work-0.5.3」フォルダを(必要なファイルがあれば保存してから)削除します。 パッケージ化を実行します。新たな「download」フォルダと「work-0.5.3」フォルダが作られます。

-

パッケージをインストールして動作確認。

それの繰り返しです。

-

注意: こちらに投稿しているやり方の、手動で作成した「.patchset」はプルリクエストに使えないので、「個人的に使う」だけにして下さい。

→個人的にはパッチが動けばOK です。念の為に形式を合わせましたが、手動で作成した「.patchset」はプルリクエストしても受け付けてもらえませんでした。

ヘッダー部とフッター部を追加したときに、パッチの動作には無関係と思ってヘッダー部の1行目を適当に作成したのが良くなかったのでしょう。正式?な「.patchset」ファイルを作成してくれる「ツール」とか、正式な形式の書き方とかを知りたいところ。ネットでは情報はヒットしません。

もしかしたら、「BeBook」をインストールして覗いてみれば、書かれているかもしれません。 まずは、他を片付けてからです。

-

-


--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - -----

-

1. システム更新:

-

コマンドで、システム更新:

~> pkgman refresh
~> pkgman update

-

-


--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- -

-

2. 日本語入力「mozc」のインストール:

-

アプリの移植とは関係ありませんが、日本語入力できると便利です。

-

「mozc」のインストール:

~> pkgman install mozc

→インストールで右上のパネルのシステムトレイに「キーボード」アイコンが表示され、 再起動しなくても「半角/全角」キーで日本語オン/オフして、日本語入力できました。

-

残念ながら、日本語入力で「インライン変換」できるのは、今のところ、Haiku 向けに作られたアプリのみです。

Haiku に移植されたほとんどのアプリは「インライン変換」ではなく、日本語変換の窓が入力している位置よりも離れた場所に表示されます。視界から入力位置がズレているので入力しづらいです。

-

Linux とは違うOS なので、入力に使われている関数の作りも違うようです。 初期のLinux ではほとんどが「インライン変換」できませんでした。 なので、それができるしくみができれば、使い勝手も大きく違ってくると思います。

-

-


--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- --

-

3. パッケージ作成ツールの「haikuporter」をインストール:

-

参考:

Building packages with haikuporter

-


1). 「python3」のインストール:

ツールに必要です。

-

(1). パッケージの確認:
> pkgman search python3 | grep Core
:
        packaging_python3               Core utilities for Python packages       ←(Python 3.7-10-5)
        packaging_python38              Core utilities for Python packages      ←(Python 3.8)
        packaging_python39              Core utilities for Python packages      ←(Python 3.9)

→3つのバージョンの python3 から選べます。標準の3.7 を選択。 好みで選ぶのではなく、ツールがどれで出来ているかです。これが無難そう。

-

(2). 「python3」のインストール:
> pkgman install packaging_python3

> pkgman search python3 | grep Core
S       packaging_python3               Core utilities for Python packages                                              
        packaging_python38              Core utilities for Python packages                                              
        packaging_python39              Core utilities for Python packages                              

→行頭に「S」が付くのがインストールされている印です。

-

バージョンの確認:

> python3 --version
Python 3.7.10

-

参考: ちなみに、「python3」がインストールされていない場合:

haikuporter の起動でエラー:

~> cd ~/Git/haikuporter/
> haikuporter --help
env: 'python3': No such file or directory

-


2). 「HaikuPorter」ツールと、すべてのRecipes(レシピ)を含む「haikuports」ツリーを入手:

-

(1). 「git」があるか確認:
~> git --version
git version 2.30.2

-

(2). 「Git」フォルダの準備(任意):
~> cd
~> mkdir Git
~> cd Git

→サイト上のガイドでは作っていませんが、大文字を入れるとわかりやすくなるので管理が楽です。

-

(3). 「haikuporter」ツールを入手:
~> cd ~/Git/
~/Git> git clone https://github.com/haikuports/haikuporter.git --depth=30

Cloning into 'haikuporter'...
remote: Enumerating objects: 213, done.
remote: Counting objects: 100% (213/213), done.
remote: Compressing objects: 100% (142/142), done.
remote: Total 213 (delta 98), reused 136 (delta 67), pack-reused 0
Receiving objects: 100% (213/213), 153.94 KiB | 967.00 KiB/s, done.
Resolving deltas: 100% (98/98), done.

Python の「haikuporter」ツールが入った「haikuporter」フォルダが作られました。

-

(4). 「haikuports」ツリーを入手:
~> cd ~/Git/
~/Git> git clone https://github.com/haikuports/haikuports.git --depth=30

Cloning into 'haikuports'...
remote: Enumerating objects: 14439, done.
remote: Counting objects: 100% (14439/14439), done.
remote: Compressing objects: 100% (9723/9723), done.
remote: Total 14439 (delta 3460), reused 11607 (delta 2814), pack-reused 0
Receiving objects: 100% (14439/14439), 15.52 MiB | 270.00 KiB/s, done.
Resolving deltas: 100% (3460/3460), done.
Updating files: 100% (5296/5296), done.

→「haikuports」ツリーが入った「haikuports」フォルダが作られました。すべてのアプリが「.recipe」ファイルを持ち、カテゴリ別にフォルダ分けされています。

-

  • 「--depth=30」を付けて、クローン作成を最後の30 コミットまでに制限、ダウンロード時間とディスク容量を節約。もう少し減らしてもいいかも。逆に最新のソースでなく、過去のソースが必要なら増やす必要があります。

-

(5). 2つのフォルダが作成されました:
~> ls -1 ~/Git/
haikuporter   ←(ツールがあるフォルダ)
haikuports   ←(ツリーがあるフォルダ)

Haiku のガイドでは、「Git」フォルダは作成されていません。任意ですが管理しやすくなります。

-


3). HaikuPorter の「パス」の設定:

  • HaikuPorter コマンドの「パス」を通して、他のコマンドと同じように使えるようにリンクを作成:
~> cd ~/Git/haikuporter/

> ls -l
:
-rw-r--r-- 1 user root  190 9月  25 23:41 AUTHORS.txt
drwxr-xr-x 1 user root 2048 9月  25 23:41 buildmaster
drwxr-xr-x 1 user root 2048 9月  25 23:41 doc
drwxr-xr-x 1 user root 2048 9月  25 23:41 generic
-rwxr-xr-x 1 user root  623 9月  25 23:41 haikuporter
drwxr-xr-x 1 user root 2048 9月  25 23:41 HaikuPorter
-rw-r--r-- 1 user root 2237 9月  25 23:41 haikuports-sample.conf
-rw-r--r-- 1 user root 3258 9月  25 23:41 README.md
-rwxr-xr-x 1 user root  625 9月  25 23:41 setup.py
drwxr-xr-x 1 user root 2048 9月  25 23:41 tools

> ln -s haikuporter ~/config/non-packaged/bin/

> ls -l ~/config/non-packaged/bin/
:
lrwxrwxrwx 1 user root 11 9月  25 23:46 haikuporter -> haikuporter

→これを見るといつインストールしたかがわかりますね。

-


4). HaikuPorter の設定:

-

(1). haikuports の設定ファイル「 haikuports.conf」をコピー:
~> cd ~/Git/haikuporter/
~/Git/haikuporter> cp haikuports-sample.conf ~/config/settings/haikuports.conf

-

(2). 「 haikuports.conf」の修正:
> lpe ~/config/settings/haikuports.conf

→「lpe」コマンドでGUI の「Pe」が起動されます。ハイライト表示されて見やすいです。

左下に行番号が表示されます。

Pe やStyledEdit は、日本語を含んでいると文字化けしやすいので、日本語は避けた方が無難。(文字コードのデフォルトがユニコードUTF-16 でなく、UTF-8 です。日本語のファイルに書き込むと、違う文字コードで書き込まれ文字化け)

-

TREE_PATH

→haikuports ツリーのクローンを作成した場所 (例: 「/boot/home/haikuports」)

TREE_PATH="/boot/home/Git/haikuports"

-

PACKAGER

パッケージの作成者です。

→あなたの名前とメールアドレス (例: 「Humdinger humdinger@mymail.com」)

FuRuYa7 <mymail@mydomain.org>

→自分のPC にインストールした「git」 に登録した名前とメールアドレス(任意、ダミーでも必要)です。

-

TARGET_ARCHITECTURE="x86_gcc2"

アプリが対応するアーキテクチャ

TARGET_ARCHITECTURES="x86_64"

→つまり、64ビット アプリを使うということ 以前の「all !x86_gcc2」は使えなくなっていました。

-

SECONDARY_TARGET_ARCHITECTURE="x86"

32ビットアプリを使うことがあるかどうか。

#SECONDARY_TARGET_ARCHITECTURE="x86"

→32ビット アプリ(以前のアプリ)を使わないのならコメントを解除せずにそのままにします。

これは、公式の32ビットHaiku(gcc2hybrid)を実行するためのものです。古いgcc2 コンパイラBeOS 互換性を維持するためのデフォルトです。「x86」は古いgcc2 でビルドされないアプリケーション用の最新のコンパイラ(現在はgcc5.4)です。

-

→修正が終わったら、保存

-

ちなみに、「SECONDARY_TARGET_ARCHITECTURE=」のコメントを解除した場合:

抜粋:

        updating dependency infos of kunitconversion-5.80.0
        updating dependency infos of kunitconversion_x86-5.80.0

→チェックしたときに 2つの版が準備されました。 32ビット アプリは使わないし時間と容量は少ない方が良いので、コメントのままにしました。

-


5). haikuporter の確認:

-

バージョンの確認:
~> cd ~/Git/haikuporter/
~/Git/haikuporter> haikuporter --version
haikuporter 1.2.6

→これで、HaikuPorter が使えるようになりました。

-


6). 便利なコマンドを使えるようにしました:

  • 「inpatch 文字列」 →パッチファイルで、「文字列」を含む行を表示

  • 「inrecipe 文字列」 →レシピファイルで、「文字列」を含む行を表示

  • 「hp パッケージ名」→パッケージの作成をするコマンドの簡略型です。

-

「~/config/settings/profile」の作成:
> cd ~/config/settings/
> lpe profile

下記を追記:

function inpatch () { grep -rni $1 /boot/home/Git/haikuports/*/*/patches/*; }
function inrecipe () { find /boot/home/Git/haikuports -maxdepth 3 -name "*.recipe" \
| xargs grep -ni --col $1; }

alias hp="haikuporter -S -j2 --no-source-packages --get-dependencies"

→シェル関数を 2つとエイリアスを定義しました。 エイリアスの「-j2」の値は自分のPC が持つプロセッサ数を入れると処理が速く終わります。

-

誤って入力した、シェル関数を削除:
~> unset inpatches

-

再起動

-

定義したシェル関数を表示:
~> declare -f
inpatch () 
{ 
    grep --color=auto -rni $1 /boot/home/Git/haikuports/*/*/patches/*
}
inrecipe () 
{ 
    find /boot/home/Git/haikuports -maxdepth 3 -name "*.recipe" | xargs grep -ni --col $1
}
whence () 
:

-

使い方:

-

パッチファイルで、「makefile」を含む行を表示:
~> inpatch makefile

-

レシピファイルで、「koader」を含む行を表示:
~> inrecipe koader

-

パッケージの作成:
~> cd ~/Git/haikuporter/
~/Git/haikuporter> hp koader

→以降にある、「4. 「haikuporter」ツールを使う:」になってから試してください。だんまりになります。

-


7). ヘルプの表示:

「haikuporter」のすべてのオプションを表示

~> cd ~/Git/haikuporter/
~/Git/haikuporter> haikuporter --help

Usage: haikuporter [options] portname[-portversion]

Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -l, --list            list available ports
  --list-packages       list available packages
  -a, --about           show description of the specified port
  -s, --search          search for a port (regex)
  --search-packages     search for a package (regex)
  -o, --location        print out the location of a recipe (via search, for
                        scripted editing)
  -q, --quiet           suppress output from build actions
  -v, --verbose         show why the recipe is broken
  -y, --yes             answer yes to all questions
  -j JOBS, --jobs=JOBS  the number of concurrent jobs to build with
  -S, --strict-policy   require strict packaging policy adherence; packaging
                        will fail on any policy violation
  --debug               show Python stack traces for fatal errors
  -n, --nopatch         don't patch the sources, just download and unpack
  -e, --extract-patchset
                        extract current patchset(s) from port source(s)
  -G, --no-git-repo     don't create git-repo(s) for port source(s)
  -B, --patch-files-only
                        don't build the port, just download, unpack and apply
                        patch files; don't call PATCH() though
  -b, --nobuild         don't build the port, just download, unpack and patch
  -p, --nopackage       don't create package, stop after build
  --all-dependencies    build all outdated dependencies for the given port.
  --get-dependencies    install all needed dependencies, then build the port
  --update-dependencies
                        build or update required dependencies (stop on hpkg),
                        then build the port
  --missing-dependencies
                        build missing direct and indirect dependencies, then
                        build the port
  --no-source-packages  don't create any source packages
  --test                run tests on resulting binaries
  -C, --nochroot        build without a chroot()-environment - meant for
                        debugging the build/install process
  -E, --enter-chroot    just enter the chroot()-environment, do not build
  -f, --force           force to perform the steps (unpack, patch, build)
  -F, --preserve-flags  don't clear any flags when a changed recipe file is
                        detected
  -P PORTSFILE, --portsfile=PORTSFILE
                        handle all ports in the given file
  --create-source-packages
                        build only the (regular) source packages
  --create-source-packages-for-bootstrap
                        build only source packages as required by thebootstrap
                        image
  --do-bootstrap        build all packages with cyclic dependencies
  -w WHY, --why=WHY     determine why the given port is pulled in as a
                        dependency of the port to be built
  -D, --analyze-dependencies
                        analyze dependencies between ports and print
                        information; no port parameter required
  -c, --clean           clean the working directory of the specified port
  --purge               clean the working directory and remove downloads of
                        the specified port
  -g, --get             get/update the ports tree
  -t, --tree            print out the location of the haikuports source tree
  --lint                scan the ports tree for problems
  --config=CONFIGFILE   specifies the location of the global config file; the
                        default is "~/config/settings/haikuports.conf"
  --cross-devel-package=CROSSDEVELPACKAGE
                        path to the cross development package (the actual
                        "sysroot" package); the default (when cross-building
                        at all) is the one to be found in
                        "/boot/system/develop/cross" matching the target
                        architecture
  --secondary-cross-devel-packages=SECONDARYCROSSDEVELPACKAGES
                        comma-separated list of paths to a secondary cross
                        development package (the actual "sysroot" package);
                        one path must be specified for each configured
                        secondary target architecture (specified in the same
                        order)
  --licenses=LICENSESDIRECTORY
                        path to the directory containing the well-known
                        licenses; the default is "<systemDir>/data/licenses"
  --system-mimedb=SYSTEMMIMEDB
                        path to the directory containing the system MIME DB;
                        the default is "<systemDir>/data/mime_db"
  --command-mimeset=COMMANDMIMESET
                        specifies the "mimeset" command; the default is
                        "mimeset"
  --command-package=COMMANDPACKAGE
                        specifies the "package" command; the default is
                        "package"
  --command-package-repo=COMMANDPACKAGEREPO
                        specifies the "package_repo" command; the default is
                        "package_repo"
  --cross-tools=CROSSTOOLS
                        specifies the path to the cross-tools directory
                        created by the Haiku build system's configure script
  --sourceforge-mirror=SOURCEFORGEMIRROR
                        mirror to be used for sourceforge
  --no-system-packages  do not use system packages to resolve dependencies
  --system-packages-directory=SYSTEMPACKAGESDIRECTORY
                        specifies the directory to be used to look up system
                        packages (only applies to build master mode)
  --list-dependencies   list dependencies of a port
  --build-master        run as build master and delegate builds to builders
  --build-master-output-dir=BUILDMASTEROUTPUTDIR
                        specifies where build master output shall be written
  --local-builders=LOCALBUILDERS
                        number of local builders
  --console             display a build master curses console
  --repository-update   update dependency infos in the repository
  --check-repository-consistency
                        check the consistency of the repository
  --no-repository-update
                        do not update dependency infos in the repository
  --no-package-obsoletion
                        do not move obsolete packages out of packages dir
  --prune-package-repository
                        prune the package repository
  --create-package-repository=CREATEPACKAGEREPOSITORY
                        create a package repository at the given output path
  --check-package-repository-consistency
                        check consistency of package repository by dependency
                        solving all packages
  --literal-search-strings
                        treat search strings as literals instead of as
                        expressions
  --print-raw           print machine readable output for use by scripts
  --print-filenames     print filenames instead of package names in package
                        listings and searches
  --ignore-messages     ignore messages within recipes
  --ports-for-files     list all ports affected by the supplied list of files
  --ports-for-packages  list ports producing the supplied list of packages
  --active-versions-only
                        only check in active versions of ports instead of all
                        ports
  --check-ports-releases
                        check for newer releases of ports published upstream

→この一覧が表示されないと、haikuporter の準備に失敗しています。

ports 名だけでなく、ports のバージョン名が指定できるのがポイント。

-

-


--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ---

-

4. 「haikuporter」ツールを最初に起動したとき、すべての更新が実行:

-

セットアップ後に、最初に起動したときのみ、全ての「ports」のチェックと更新が実行されます

ヘルプとバージョンの表示を除いた、どのコマンドを使っても、最初だけ、全ての「ports」のチェックと更新が入ります。更新されないと前に進みません。

また、「ports」の中に、使われるアーキテクチャごとに作業ファイルが作成されます。

-

例: 最初に「ports」の更新を確認:

~> cd ~/Git/haikuporter/
~/Git/haikuporter> haikuporter -v

Warning: Found old repository format - repopulating the repository ...(水色のメッセージがひとつ)

:
packageEntries: warning: "devel" doesn't seem to be a valid package suffix.
packageEntries: warning: "devel" doesn't seem to be a valid package suffix.

→和訳:

警告:古いリポジトリフォーマットを見つけました - リポジトリの再配置... : packageEntries: 警告:「devel」は有効なパッケージサフィックスではないようです

haikuporter (どのコマンドでも)を起動した最初にだけ表示。設定に合わせたツリーの正常性や更新をチェックをしているみたい。

→処理中しばらくだんまりになるので、何を実行しているのかわかるように、最初だけコマンドに「-v」を付けました。ports のアルファベット順にメッセージが流れるので時間の経過がわかり安心できます。

-

遅いUSB メモリを使っていると1時間ほど、だんまりになります。 USB 2.0 のUSB メモリの場合、1時間ほどで正常に戻りましたが、何もできなくなりました。 USB 3.0 ならもっと早く終わるはずです。

しばらくパソコンが使えなくなるかもしれないので、タイミングを見計らって実施します。 更新が終われば、更新されていない個別の「ports」だけが対象なので、通常の速度に戻ります。

-

-


--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----

-

5. 「haikuporter」ツールを使う:

-


1). すべての「ports」の更新と状態を確認:

~> cd ~/Git/haikuporter/
~/Git/haikuporter> haikuporter -v

-

レシピが置かれたフォルダに「work-0.9.2 」のようなバージョン番号を含んだフォルダが自動で追加されました:

パッケージ化の前のビルドする時の作業フォルダです。32 ビットも指定すると、さらに「x86」付きのフォルダが増えます。

> cd /boot/home/Git/haikuports/app-editors/featherpad/
> ls -1
additional-files
featherpad-0.9.2.recipe
work-0.9.2

> ls -1 work-0.9.2
port.recipe  ←内容は「featherpad-0.9.2.recipe」と同じ

-

2). 有効な ports の一覧表示:

  • 「ローカルのリポジトリ」にパッケージ化する前のソースがあるかの表示
~/Desktop> cd
~> haikuporter --list
bash: haikuporter: コマンドが見つかりません

~> cd ~/Git/haikuporter
~/Git/haikuporter> haikuporter --list
0ad
0ad_data
:
zziplib

→パスが通っていません。

-

3).「grep」で欲しいアプリがあるかを確認:

~/Git/haikuporter> haikuporter --list | grep font

arabeyes_fonts
croscorefonts
farsi_fonts
fira_fonts
fontawesome     ←(注目)
fontboy
fontconfig
fontforge
fontsproto
fonttools
fontutil
kacst_fonts
lateef_font
lato_fonts
liberation_fonts
libfontenc
libxfont
msttcorefonts
nanumfont
scheherazade_font
timgmsoundfont
ubuntu_font_family
ukijorgfonts
unifont
urw_base35_fonts
x_series_fonts

Haiku での「grep」は抽出、および、該当文字列が「赤く」表示されます。

-

4).「リモートのリポジトリ」にパッケージ化されたアプリがあるかの表示:

~/Git/haikuporter> pkgman search fontawe
Status  Name         Description                            
------------------------------------------------------------
        fontawesome  A font containing scalable vector icons

→こちらは、ダウンロードした「ローカルのリポジトリ」でなく、ネット上のリポジトリにあります。 すでにパッケージ化された状態なので、すぐにインストール可能です。

-

  • ports をダウンロードして、「ローカルのリポジトリ」を作成する利点は、ソースがあり、パッケージ化する前なので、自分で加工しやすいこと。

-

-


--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- -----

-

6.「haikuports」ツリーにて、Linux から移植されたアプリを確認:

-


例: テキストエディタ「featherpad」:

-

在り処の表示:
~/Git/haikuporter> haikuporter --location featherpad

もしくは、

~/Git/haikuporter> haikuporter -o featherpad
/boot/home/Git/haikuports/app-editors/featherpad
/boot/home/Git/haikuports/app-editors/featherpad_x86

→32 ビットも指定していた場合に、「_x86」の行は表示(ports が作成)されます。 指定されていないときは、表示(作成)されません。

-

> cd /boot/home/Git/haikuports/app-editors/featherpad/
> ls -1
additional-files         ←(アプリによっては、あったりなかったり)
featherpad-0.9.2.recipe    ←(レシピファイル: 必須)
work-0.9.2            ←(作業フォルダ)自動で作られたもの

-

> ls -1 additional-files/
featherpad.rdef.in      ←(featherpad.rdef に付け加えたい内容を記述)

> ls -1 work-0.9.2
port.recipe           ←( featherpad-0.9.2.recipe と内容は同じ)

→作業フォルダは更新チェック、またはパッケージの作成時に自動的に作成されます。 最初は「レシピ」ファイルのみが入っています。

-

-


--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- -

-

7.「haikuports」ツリーにて、Haiku 専用に作られたアプリを確認:

-


例: テキストエディタ「koder」:

-

在り処の表示:
~/Git/haikuporter> haikuporter -o koder
/boot/home/Git/haikuports/haiku-apps/koder

> cd /boot/home/Git/haikuports/haiku-apps/koder/
> ls -1
koder-0.5.3.recipe        ←(レシピファイル: 必須)
work-0.5.3             ←(作業フォルダ)自動で作られたもの

→アプリによりますが、「.rdef.in 」はソースの方に準備されていました。

-

→移植されたアプリだけでなく、Haiku のアプリも確認や修正ができます。感謝。

-

  • GitHub の「haikuports/haikuports 」に置かれているファイルが (ダウンロードされて)こちらに表示されています。

→「haikuports」にて、作業した成果(例えば、日本語化したアプリのレシピやパッチ)をアップしたいときのプルリクエスト先になります。

-

-


次の投稿に続く

-

-


まとめ

「HaikuPorter」ツールと、レシピファイルとパッチファイルを含んだ「haikuports」ツリーを入手しました。

レシピファイルは、Arch Linux の特徴といえるAUR で使われる「PKGBUILD 」ファイルと似たものと理解しました。たぶんベースは同じなんだろうと思います。理解の助けになったので、色々と手を出しておくべきですね。

-

ただし、プログラム言語のスキルが不足しているのがこれからの問題になりそう。

HaikuLinux ではありませんが、Linux からのアプリの移植が進んでいるのは、Haiku の特徴のひとつの「POSIX 互換」が大きく、アプリが「POSIX」に沿った作りであれば移植しやすいのだろうと思います。逆に有名どころの中にはそれに沿っておらず移植しづらいアプリがあるかもしれません。

-

環境が整ったので、これでアプリの日本語化に挑戦できます。

-

-


-

-

    目次

-

「投稿の先頭 へ」

-

-


-

「この目次 の先頭へ」

「本編の目次 に戻る」

-