z80oolong さんはインスタンス qiitadon.com のユーザーです。アカウントさえ持っていればフォローしたり会話したりできます。 もしお持ちでないなら こちら からサインアップできます。

z80oolong @z80oolong@qiitadon.com

# 現在の技術案件の近況

今回も、 proot に関する近況について述べる。

## proot 案件

前回の投稿で、 proot の Pull Request について述べたが、これはオリジナル版にマージされたものでは無く、 rootlesscontainers の開発コミュニティ版の proot へのものであった事が判った。

これに伴い、[先日 Qrunch 諸島に投稿した記事][1]について、表題及び内容の大幅な訂正を行った。何とも不覚である。

しかしながら、 proot が rootlesscontainers や uDocker に対応する事が可能となれば、 OCI 準拠のコンテナイメージ等を Android OS 端末上で使用出来る可能性がある事が考えられる。

そして、Docker 等の各種コンテナ型仮想化技術に基づく手法を用いて Android OS 端末上で動作する各種 Linux 系ディストリビューションを構築する事が容易になりそうである。

[1]:z80oolong.qrunch.io/entries/gB

# 現在の技術案件の近況

今回は、 proot に関する動きについて述べる。

## proot 案件

proot は、 Debian noroot 環境において、最も重要かつ根幹的な役割を持つツールである。

ここで、[オリジナルの proot の GitHub リポジトリ][1]において、 Akihiro Suda 氏によって、新たに大幅な変更を加えた Pull Request がマージされた。

今回のマージでは、 udock 対応や、 rootlesscontainer 対応等、 proot に container に関する機能を追加する変更が多く含まれている事が特徴である。

また、この変更に伴い、 proot に依存するライブラリとして talloc の他に、 protobuf が追加される見通しである。

Termux の開発コミュニティによる proot への反映については未定だが、非常に大きな変更である事は明らかであると思われる。

この件に関しては、追って別件にて述べる予定である。

[1]:github.com/proot-me/PRoot

# 現在の技術的案件の近況

## z80oolong/go 案件

先日、手元の端末で公式の Go 言語の処理系を導入しようとして、 linuxbrew を使用して導入を行おうとした所、手元の端末が ARM アーキテクチャ搭載の端末であったのと、 linuxbrew のコア Tap リポジトリに置かれている homebrew/core/go が x86-64 アーキテクチャ以外に対応していなかった為、 homebrew/core/go を修正し、[独自の linuxbrew 向け Tap リポジトリ][1]を作成する必要があった。

オリジナルの Formula である homebrew/core/go と異なり、 64 bit x86 CPU アーキテクチャ搭載の端末の他に、 32 bit ARM CPU アーキテクチャ及び 32 bit x86 CPU アーキテクチャ搭載の Linux 系 OS 等への公式の Go 言語処理系の導入にも対応させた。

[1]:github.com/z80oolong/homebrew-

# 現在の技術案件についての近況

## powerline 案件

Github 上の HEAD 版の tmux において powerline の設定を行うと、 tmux のステータスラインがデフォルトの状態で全く変化が無い問題について、問題の概要及び原因とその回避手法を Qiita 半島に投稿した。

今般の問題は、 powerline が異常な tmux のバージョンに対しても適切な動作を行う事を保証するのが良いのか、若しくは、 Github 上の HEAD 版の tmux が常に "master" なるバージョンを出力するようにすれば良いのか、若干考え込んでしまった。

## libandroid-shmem.so 案件

libandroid-shmem.so の導入手法に関する案件については、更なる検証作業を行った結果、 pelya 氏によるオリジナルのものの方が Termux の開発コミュニティのものと比較して buggy であったものの、実行時間については有意差が認められなかった。

即ち、 Termux の開発コミュニティのものは安定して動作するという知見を得た。

# 現在の技術的な近況

現在うだうだ中。現在、自宅にて休息中。幾つかの技術案件の近況について纏める。

## powerline 案件

さて、EAW 文字の全角文字幅表示対応の tmux に powerline を導入する案件であるが、当初は、 GitHub 上の HEAD 版 tmux において powerline を動作させるべく、 tmux に各種設定を行なっても、 tmux のステータスバーに変化が無く、 powerline が正常に動作しない問題が発生していた。

この件に関して、先ず最初に、 powerline のソースコードを修正する事で問題を解決したが、その後、 tmux のバージョン出力を修正する事によっても問題回避が可能である事が判り、 tmux のソースコードを修正した上で オリジナルの powerline を導入した所、問題回避が可能となった事が判明した。

以上の件について、以下の[Qrunch 諸島の投稿][1]に追記及び修正を行った。

[1]:z80oolong.qrunch.io/entries/HQ

## powerline 案件

さて、当方は普段より tmux を EAW 文字対応の差分ファイルを適用して使用しているが、久し振りに、 powerline を tmux に導入しようと思い立ち、 powerline 公式ページ他、各種ページを参考にして導入を行った。

当初は、 $HOME/.local への導入を検討したが、最終的に、 Linuxbrew との統合的なパッケージの管理を考慮し、 Formula を記述して Linuxbrew に導入した。

しかし、各種ページを参考にして $HOME/.tmux.conf に設定を記述しても tmux のステータスバーに変化が無く、原因究明に非常に苦慮した。

最終的に、 tmux のバージョン番号の出力に問題がある事が原因である事が判明し、 powerline のソースコードを修正する事で何とか問題を解決した。

以上の問題解決について、以下の[Qrunch 諸島の投稿][1]に纏めた。

[1]:z80oolong.qrunch.io/entries/HQ

# 現在の技術案件の近況

現在うだうだ中。今週は先週と異なり、若干の諸用が入るも、先週に引き続いて時間に余裕のある状況となる。

## libandroid-shmem.so 案件

先週より、 [Debian noroot 環境において、 Termux の開発コミュニティによる移植版][1]を再移植したものを導入するに当たって、幾つかの動作の不具合について修正を行なった。

その結果、先週末から昨日までに動作の不具合に関する問題は凡そ解決された。

最終的に、速度面ではオリジナルと有意差は見られなかったが、共有メモリ関連のテストプログラムの動作をオリジナルと比較した所、 Termux 版で問題無くテストプログラムが動作したものの、オリジナル版において、複数のテストプログラムが動作しなかった。

これより、 Termux 版の動的ライブラリの導入により、Debian noroot 環境の安定した動作が期待できる事が示された。

[1]:gist.github.com/z80oolong/247d

# 現在の技術案件の近況

現在うだうだ中。今週は、久し振りに時間に余裕のある一週間となるも、殆どの作業時間を後述する libandroid-shmem.so の問題の修正に費やした。

## libandroid-shmem.so 案件

libandroid-shmem.so とは、 Debian noroot 環境において、共有メモリ関連の標準ライブラリ関数の動作を、 Android OS における /dev/ashmem へのアクセスに基づくエミュレーションよって実現する為の動的ライブラリである。

Debian noroot 環境において、オリジナルのものに代えて、 Termux の開発コミュニティによる移植版を再移植したものを導入した所、環境上で動作するソフトウェアが概ねオリジナルより軽快になった。

しかし、幾つかのソフトウェアについて動作の不具合が発生する事が判明したので、オリジナルとコード等を比較しながら、 libandroid-shmem.so について動作の不具合の解決等の問題の修正を行った。

なお、修正を行った差分ファイルについては後日公開する予定である。

# 現在の技術的な近況

現在うだうだ中。現在、午前中の通常の通院案件を完了し、昼食及び休憩の為に奈良市内某所に向かい移動中。

幾つかの技術案件の近況について纏める。

## Debian noroot 環境案件

@kapper1224 氏が Debian noroot 環境について予てより懸念を示していた UI に関する問題について、 gnome3 の導入による解決を試みていたが、現在もなお gnome-shell の起動に至らず、非常に困難な状況にある。

そこで現在、もう一つの手法として、 Debian 環境等で動作する Desktop 環境である MATE を導入した上で、 gnome の以前の UI であった Unity に近いインターフェイスを実現するためのテーマである Munity を導入することを検討している。

現在のところ、 Debian noroot 環境において、問題なく MATE 環境を導入することが出来ることが確認されたが、 Munity を導入するために必要となる mate-tweak の導入に難航している状況である。

# 最近の技術的な案件について

## Qiita 案件

この度、 Qrunch への投稿のうち、1件を大幅に加筆修正して、 [Qiita に投稿した。][1]

以下に、投稿の概要を示す。

ARM 系アーキテクチャにおいて、 Linuxbrew を用いて各種パッケージを導入する場合に、 brew install コマンドを起動すると、以下のようなエラーメッセージを出力して異常終了する場合があります。

*** Error in `gcc-4.9': double free or corruption (top): 0x000b6a30 ***

そこで、ディレクトリ $HOMEBREW_PREFIX/bin 以下に、 gcc コンパイラに渡すオプションのうち、 -march=native 等を除去するためのラッパースクリプトを導入することにより、前述の異常終了の問題を回避することが可能となりました。

[1]:qiita.com/z80oolong/items/89ee

# 最近の技術的な近況

現在うだうだ中。精神的にも身体的にも季節の変わり目ということで疲労感と全身倦怠感が強い日々が続く。
ここでは、技術的な案件について近況を述べることにする。

## Qrunch (はてなブログ), Qiita 案件

先ずは、 Qrunch のアカウントを ”Qrunch 諸島” として取得したことに伴い、過去に Qiitadon.com 環礁に連続して投稿していた5件の技術的な投稿について、一旦はてな諸島に整理して再掲した上で、 Qrunch 諸島にクロス投稿した。

この中から1〜2件の投稿について、大幅な加筆及び修正の上で Qiita 半島に投稿する予定である。

## その他案件

現在、手元の Debian noroot 環境に gnome-shell を apt-get を用いて導入した上で起動を試みているが、 未だ成功していない。

また、手元の Debian noroot 環境に OpenSSH を Linuxbrew からソースに patch を当てた上で導入したところ、起動に成功した。

詳細等については、後日追って述べたい。

# 今後の Qiitadon.com 環礁について

この度、 Qrunch がサービスを開始したということで、当方も、 Qranch のアカウントを、 ”[Z.OOL.ネット信託統治領 Qrunch 諸島][1]" として取得しました。

予てより、技術的事項について呟き程度の最も簡易な短信については、こちらの Qiitadon.com 環礁に書き留めていました。

しかし、次第に速報性の高い技術的な短信を書き留めるには、 500 文字の投稿の連続では制約が大き過ぎる状況が多くなってきました。

そこで、これまで Qiitadon.com 環礁に書き留めていた技術的事項の最も簡易な短信の投稿を Qrunch 諸島に書き留めていくことにしました。

現状では Qrunch 諸島はスマートフォンからの記事の投稿が困難なので、当面は、はてな諸島とのクロス投稿の形式を取ると思います。

また、今後は、 Qiitadon.com 環礁は技術案件の近況を書き留める事になるかと思います。

今後とも、どうか宜しくお願い致します。

[1]: z80oolong.qrunch.io/

# Linuxbrew において ARM 系アーキテクチャで brew install が異常終了する問題を回避する

## 概要

ARM 系アーキテクチャにおいて、 Linuxbrew を用いて各種パッケージをビルドする場合に、 brew install コマンドを起動すると、以下のようなエラーメッセージを出力して異常終了する場合があります。

*** Error in `gcc-4.9': double free or corruption (top): 0x000b6a30 ***

そこで、ディレクトリ $HOMEBREW_PREFIX/bin 以下に、 gcc コンパイラに渡すオプションのうち、 -march=native 等を除去するためのラッパースクリプトを導入することにより、前述のような brew install コマンドが異常終了する問題を回避することが可能となりました。

## 詳細

詳細については、以下の記事を御覧下さい。

[1]:z80oolong.qrunch.io/entries/fj

## Firefox ESR のダウングレード

そして以下のようにして、パッケージ ```firefox-esr_45.9.0esr-1~deb8
1_armhf.deb``` をインストールします。

$ sudo gdebi ./firefox-esr_45.9.0esr-1~deb8
1_armhf.deb

## Firefox ESR の動作確認

最後に、以下のようにして、バージョン 45.9 にダウングレードした Firefox を起動して、 Firefox が正常に動作するか確認します。

$ firefox &

上記のダウングレードにより、 Firefox の画面が正常に表示されれば、 Firefox ESR が問題無く動作する事が判ります。

## ダウングレードの準備

本稿では、 Firefox ESR のバージョンを 45.9 にダウングレードする手法について述べます。

まず最初に、ディレクトリ /var/cache/apt/archives において、ファイル ```firefox-esr_45.9.0esr-1~deb8
1_armhf.deb``` が存在する事を確認し、このファイルを適当なディレクトリに以下のようにコピーします。

$ cp /var/cache/apt/archives/firefox-esr_45.9.0esr-1~deb8
1_armhf.deb .

次に、任意の .deb ファイルをインストールするためのソフトウェアである gdebi を以下のようにインストールします。

$ sudo apt-get install gdebi

# Debian noroot 環境において Firefox の動作に関する問題とその回避策について

## 概要

Debian noroot 環境において Firefox ESR を導入した場合、最新の Firefox を起動すると、 Firefox の画面が何も表示されない障害が発生することがあります。

これは、 Firefox の起動時に共有メモリに関するディレクトリ /dev/shm を参照した時に、 /dev/shm が一般ユーザに対してアクセス権限が適切に与えられない状態にある事が原因であると考えられます。

また、 Firefox が共有メモリを Debian 環境内の標準ライブラリ関数 shmat 等を介して操作していない事も原因として考えられます。

この問題は、旧版の Firefox のうち、共有メモリを Debian 環境内の標準ライブラリ関数 shmat 等を介して操作しているバージョンにダウングレードする事によって回避する事が出来ます。

ここでは、 Firefox ESR のダウングレードによって Firefox の問題を回避する手法について述べます。

## 追記 (2018/07/01)

link2symlink 機能を実装した proot において、内部ファイル ".l2s.*" を外部から削除した場合、ハードリンクの動作に不具合が発生する問題について、以下の通りの手法で不具合が解決致しました。

即ち、 Termux の開発コミュニティによる proot のソースコードに、システムコール getdents(2) をフックするコードを追加することにより、内部ファイル ".l2s.*" が proot の子プロセスから不可視化されて、当該問題が解決しました。

システムコール getdents(2) をフックするコードの追加については、 GnuRoot の開発コミュニティによる proot のコードを参考にしました。

なお、問題を修正した proot は、[proot-termux-build の最新の安定版][1]から入手できます。

[1]:github.com/z80oolong/proot-ter

## 結論

[pelya 氏][1]による libandroid-shmem.so と異なり、 [termux の開発コミュニティ][2]による libandroid-shmem.so は、関数 shmget(2) の第一引数 key に IPC_PRIVATE 以外の値を指定出来るために、 [termux の開発コミュニティ][2]による libandroid-shmem.so の導入によって Qt の共有メモリ関連のライブラリ関数を用いたソフトウェア等が Debian noroot 環境 で正常に動作し、また、他の共有メモリを使用したソフトウェアについても動作のパフォーマンスが向上したことが判りました。

[1]:github.com/pelya
[2]:termux.com/

(続き)
この動的ファイルを使用するには、まず最初に生成された動的ライブラリを Debian noroot 環境のルートディレクトリにインストールします。

# install -v -m 0755 libandroid-shmem-termux.so /

次に、 Debian noroot 環境の初期化ファイルである /proot.sh において、環境変数 LD_PRELOAD が定義されている行を以下のように修正します。

# LD_PRELOAD="... /libandroid-shmem.so ..."
LD_PRELOAD="... /libandroid-shmem-termux.so ..." # /libandroid-shmem.so を /libandroid-shmem-termux.so に修正。

初期化ファイル /proot.sh の修正後は、 Debian noroot 環境を再起動して設定を有効にします。

(続き)
そして、入手したソースコードが置かれているディレクトリに、以下のようにして、差分ファイル libandroid-shmem-termux-0.2_1-fix.diff を適用して通常通りに make コマンドによってコンパイルすると、動的ライブラリ libandroid-shmem-termux.so が生成されます。

$ patch -p1 < /path/to/diff/libandroid-shmem-termux-0.2_1-fix.diff
(ここに、 /path/to/diff は、 libandroid-shmem-termux-0.2_1-fix.diff が置かれているディレクトリのパス名)
$ make ... (オプションを適宜設定すること。)