ぼちぼちと Plamo Linux 6.x のソース一式を修正して，qbilinux という linux ディストリビューションを作成．

いつまで続くのか．

いじってる qbilinux のビルドスクリプトは https://github.com/qblinux/qbilinux，バイナリは https://qbilinux.org/pub/ にあります．

一応，Plamo Linux とは別もので，私個人が作っているものになります．はい．

引き続き aarch64 版の立ち上げ作業．

最近はこれしかやってないです．これが落ち着いたらインストーラの調整をする予定．intel の 32bit/64bit と arm の 32bit/64bit をまとめて調整したかったもので．:-)

先日は，「なんとなくパッケージングできてる環境ができました」と書きましたが，その環境で引き続き作業．

繰り返しになりますが少し説明しておくと，32bit arm 環境の上で kernel だけ 64bit に差し替えた状態で立ち上げ．その上で LFS (Linux From Scratch) を参考に 64bit arm 用のコンパイラと glibc などの環境を構築．その環境に chroot した状態でパッケージを作成しています．

で，コンパイラ周りとか kernel 周りのパッケージングを一通りおこなってみました．一応，64bit コンパイラで kernel や glibc などがビルドできることを確認．各種ツール類も chroot 上で問題なく動作している感じなので特に問題はないかなぁと思っています．

この状態でスクリプトを一気に動かして 00, 01 カテゴリーのパッケージをすべてを作ってみました．

ということで，この辺りのファイルを https://qbilinux.org/pub/qbilinux-current/aarch64 の方に置いてあります．スクリプト自体は github の方に上げていませんが，パッケージの中には同梱していますので必要な方はそちらを参照してください．

現状は，必要最小限な aarch64 用の修正をしてるだけですけど，その過程で intel 版に対する不具合も難点か見つけました．その辺りの不具合は master に 64bit arm 用の修正をマージしてから調整する予定です．ただ，最近更新されていないソフトの中には config script の一部ファイルが古すぎて aarch64 の定義がないためにエラーになるものがちょこちょこ (結構？) あります．また，少し前に glibc を 2.28 に入れ換えたのですが，そのせいで引っかかるものもあって，なかなか完全に作業を自動化出来ずに手作業になっている部分もあります．

そんな状況ですので qbilinux-current/aarch64 以下のファイルは 1/3 くらいは壊れてる状態ですけど，まぁ，ボチボチと修正していきます．ファイルの中身が build script どドキュメントくらいしか入っていない物が壊れている物になります．はい．

とりあえずそんなところかな．

先日，debian 10 buster をためしにインストールしたって話を書きましたが，その後を．

前回はインストールして，2週間ほど使った感じでは普段使いには問題ないかなと書きましたが...，やっぱりまだ厳しい感じ．

ノートパソコンに入れてみましたが，たまにサスペンド／リジュームに失敗することがありますね．

リジューム時に電源ボタンは点灯してるんだけど，画面が真っ暗のままで復帰できないことがたまにあります．

まぁ，testing だからこれくらいのことは仕方ないんだけどね．

という感じで，アプリの動作とかは個人的に問題ないかなぁと思っていましたが，システム回りで色々とありそうな感じなのでノートパソコンでは常用はちょっと厳しいかなという印象．

参考までに使っているノートパソコンは ThinkPad X250 です．

ってことで，ノートパソコンは debian 9 stretch に戻しました．stretch だと全く問題なく使えていますね．はい．

使っている機種によって色々とあるとは思いますが，参考まで．

最近，ふとこの blog のアクセス状況を見てみたら，「FOSSIL のハイブリッドスマートウォッチ購入してみました」の記事の参照が多いみたい．

1年近く前に書いたものなんだけどね．内容はハイブリッドスマートウォッチの簡単な説明とレビューになっています．はい．

一応，説明しておくと，ハイブリッドスマートウォッチとは，普通のスマートウォッチとは異なって外見は普通の時計です．その時計がスマホと連動することで，メールや LINE などを受信したときに，時計が振動することなどで通知することができます．誰からの通知か，とか，どのアプリからの通知かは，アプリで指し示す針の位置を設定することにより判別することができます．(言葉で説明することが難しいですね．詳細は過去の blog の方を見てください)

ということで，購入後，現在まで1年ほど使っていますが，その感想を簡単に書いてみたいと思います．

結果から書くと，ほぼ普段使いの時計はこればかり使っている感じです．使っているのは，過去の blog で購入したって書いた FOSSIL の Q CREWMASTER ブラックシリコン ハイブリッドスマートウォッチ ね．で，満足度はかなり高く，不満に思っているところはほとんどない感じです．

第一にやっぱりデザインが気に入ってるかな．

やっぱりそこが一番大きいです．普段身につけるものなので，やっぱりデザインが気に入らないとあんまり使わなくなりますので...．いくつか持っている時計の中でも，お気に入りの方のデザインですね．最近の FOSSIL のものはこれほど変わったデザインのものもないので，ちょっと残念かなと思ってます．最近だと，同じ FOSSIL グループですけど DIESEL の方がデザインは好みかなぁと感じています．DZT1015 とかー．

あと通知機能はやっぱり便利です．

リアルタイムでは通知は受け取れず，数分遅れなどの通知になりますが，鞄のなかにいれたままのスマホにメールや LINE が来たってことが時計でわかるのはかなり便利です．最初，通知の際に時計が振動するバイブの強さがちょっと弱いかなぁと思っていましたが，慣れれば問題ないですね．気が付かないってことはほとんどなくなりました．まぁ，その辺りは個人差があると思いますので，みなさんがそうなるかは分かりませんが．:-)

最後に，電池の持ちはすばらしいです．

この時計は，充電不要でボタン電池で駆動します．ボタン電池ですので，いざとなればコンビニ等で電池を購入して簡単に電池交換できると言うことで選びましたが，電池の持ちはすばらしいです．やっぱり「毎日充電しないとダメ」とか「旅行の際に充電器を持っていかないとダメ」って言うのは面倒ですからね．時計を購入してから1年以上経過していますが，私の場合はまだ一度も電池交換していません．ホームーページでは最長６ヶ月くらいと記載されていますが，１年以上持っています．まぁ，使い方とか通知の頻度にも因るのかも知れないですけど．

参考までに私が使っている機能としては，メール／アプリの通知機能と，歩数計（アクティビティトラッキング）くらいです．写真を撮ったり，音楽プレーヤーのコントロールなどには使用していません．また，使っているスマホは iPhone です．

という感じで，かなり満足して使っています．

気になる点と言えば，ベルト（ストラップ）の汚れとかテカリとかですかねぇ．さすがに色々なところに摺れたせいか，シリコン製のバンドにテカリとか汚れが出てきました．まぁ，このあたりはもっとひどくなって気になるようになれば，新しいものを購入して交換すれば良いだけなんだけどね．この時計の場合には 22mm 幅なのでそれにあったものを選べば交換可能ですね．このあたりを見ると，最初についているものと同じベルトは FOSSIL から直接 3,780円 くらいで購入できるみたいです．シリコン製だけじゃなくて，革製などいろんなものもそろっていますので，同じ幅のものを選べば今までとは異なる種類のベルトも選べます．

一方，時計本体の方にはほとんど傷などもなく，きれいな状態です．はい．

まぁ，ざっとそんな感じですが，かなり愛用しています．

ハイブリッドスマートウォッチではなく，普通のスマートウォッチもどうかなぁと思うことがあり，店頭などでもたまに色々と触ってみますが，やっぱり私の場合は普通の時計の方が好みかなと感じでいます．以前書いたことの繰り返しになりますが，普通のスマートウォッチをいじってるとどうしてももう少し大きな画面のものが欲しいなぁと感じてしまうんですよ．機能やデザイン的には CASIO の protorek smart WSD-F30 なんか良いなぁと思うんですが，店頭で触ってみるとやっぱり画面が小さく感じてしまいます．けど，さらに大きな画面になるとそれってやっぱりもう時計じゃなくなってくるなぁと．それならストレスを感じながら小さい画面でいろんな文字を読むよりも，潔く時計では通知だけを受け取って，文章などはスマホで見るって割りきって使う方が使いやすいかなぁと．

そんな感じでかなり用途は絞られますが，特定用途だけでいい人で，かつ，デザインが好みのものが見つかれば，ハイブリッドスマートウォッチもかなり使いやすいと思いますので試してみるのもいいと思います．お試しに使ってみるにも普通のスマートウォッチほど値段も高くないですから．

まぁ，デザインが気に入るものを選べば，最悪，スマートウォッチではなく，ただの時計として使えばいいだけですからー．

そんなところですが，参考まで．

ぼちぼちと Plamo Linux 6.x のソース一式を修正して，qbilinux という linux ディストリビューションを作成．

いつまで続くのか．

いじってる qbilinux のビルドスクリプトは https://github.com/qblinux/qbilinux，バイナリは https://qbilinux.org/pub/ にあります．

一応，Plamo Linux とは別もので，私個人が作っているものになります．はい．

引き続き aarch64 版の立ち上げ作業をしてましたが，ちょっと問題．

一通り，基本となるパッケージをつくって aarch64 対応をしていましたが，udev のビルドがそのままでは通りません．0.2 をリリースしてから，パッケージを色々と更新したからその影響でコンパイルが通らなくなっているみたい．

試しに udev のない状態で，手元で aarch64 のインストールイメージを作ってラズパイ3に新規インストールを試してみたんだけど，インストールは出来ても，再起動後に USB 周りのコントロールが出来ないので USB キーボードを認識してくれないね．これじゃ全くデバッグできないね．

で，udev を何とかコンパイルしようと少しだけ試行錯誤してたんだけど，苦労して調整するくらいなら，ゆくゆくは udev から eudev に載せ変えようとと思ってたので，そちらの作業を先にやった方が二度手間にならずに済むかなぁと思い立ち．

環境を 0.2 リリースベースに戻せば udev の問題がなくなるかなとしれないけど，今更，戻すのも何だかなぁという感じだし．

色々いじってると，なんか芋蔓式に違うことをやる羽目になってるな．インストーラーの調整を全てのアーキテクチャでまとめてやりたいから，aarch64 の調整を始めたんだけど，そのせいで udev が通らないから eudev への差し換えって...．

udev から eudev の差し換えって，パッケージを入れ替えるって作業だけじゃ済まなくて，udev にリンクしてるバイナリを全部作り直す必要があるんだよな．それが結構な数あるので先送りにしてたんだけど...．^^;

まぁ，色々言ってても仕方ないので eudev の方の作業．とりあえず x86_64 環境で udev から eudev にパッケージを差し替え．linux ブート時に /etc/rc.d/rc.S 中で udev の設定をおこなっていますが，eudev になって依存関係が増えている関係か，そのままでは動作しないみたいだね．ってことで，rc.S 中で udev をコントロールしてるコマンド内容と，その実行位置を少しだけ調整．とりあえず動作するようにはなりました．

あとは，udev に依存していたパッケージを eudev にリンクする形に作り直して，rc.S 中で udev コントロールしてる場所とかが本当に問題ないか確認した後に，再び aarch64 環境の作業に戻る感じかな．

けど，eudev に差し替えるとインストーラーの方も以前適当に作ったものではまずいかもしれないなぁ．まぁ，それはそのときに調整する感じで良いかな．

なかなか作業が進みませんけど，まぁ少しずつやってればそのうち終わるでしょう．はい．:-)

ただの雑談です．

cakephp 3.7.0 が RC1 になりました．beta も少しだけいじってましたが，RC1 も入れてみました．

手元のコードは大きな修正は行わなくても大丈夫そうかな．

けど...，debug_kit がエラーはいてるみたいだけど，うちの環境だけなのかなぁ？

Property _transportConfig does not exist

だって．

少しだけ cakephp/cakephp/src/Mailer/Email.php を見てみましたが，たしかに 3.6.x 系列にあった

protected static $_transportConfig = [];

な宣言が 3.7.0 では削除されているようです．

うーむ．

細かいコードを追っ掛ける時間はないので，3.6.x 系列に戻しちゃいましたが，時が経てば debug_kit が修正されるのな？

追記）

やっぱり少し気になったので、もう少し調べてみました。

debug_kit は master branch を使うと駄目みたいですね。あくまで master は 3.6 系列用みたい。

3.next branch の方では修正されているようです。ということで、cakephp 3.7.x 系列を使う場合には debug_kit は https://github.com/cakephp/debug_kit/tree/3.next 以下を使いましょう。

Ryzen 5 2400G を開発用に使ってますが，64bit linux だと問題なく使えるけど，32bit linux な環境でグラフィック回りがまともに動作しません．

それが，かなり不便．

ということで，ちょっと悩み中でした．

ふと見たら，中古屋さんで AMD RX シリーズなビデオカードの値段がかなり安くなってることに気が付きました．MSI RX570 8GB なものが 15000円程度．RX580 とか RX480 になると，さすがにスペックがいいのでちょっと高いけど RX570/RX470 になると結構安くてお買得な感じ．値段を見ると一時のマイニングブームもすっかり去ってしまったようですね．

ってことで，上記のビデオカードを入手してみました．あ，詳細な型番は MSI Radeon RX 570 ARMOR 8G OC ね．

最近，NVidia なカードばかり購入していたんだけど，それもなぁと思い立ち，気分転換がてら久しぶりに RX シリーズを選んでみました．linux での RX シリーズの状況も知りたかったし．

入手したあとに，近所のドスパラで新品が 18000円 程度で売られていたのに気が付いてちょっとショックだったんだけど，まぁ，タイミングなので仕方なし．ドスパラの方は在庫のみの価格みたいですが，まだ店舗によっては残ってるかと思います．実際，近所の店舗では昨日時点 (10/27) ではまだ棚に数枚は積んでました．はい．

一瞬，この値段だともう一枚買って CrossFire も...とも思ったけど，必要ないかーって思いとどまり．RX570 を CrossFire にすると数字上は GTX1080 くらいのスペックにはなるみたいだけど，対応しているアプリじゃないと意味ないからな．

ざっとスペックを見た感じ RX570 単体では NVidia GTX1060 と同じくらいのスペックみたいですね．ただ，やっぱりゲームは NVidia への最適化が入ってるものが多いみたいでちょっと不利みたい．

デスクトップ PC に取りつけて windows で動作確認．Vega 用のドライバのまま普通に動作しました．

次，linux．

64bit debian では...映らない．Vega 用の設定が邪魔してる？調整が必要かもね．追々調べるか．

手元で作成している qbilinux ではダメダメ．Vega/Nvidia 以外の設定ってどうなっていたかちょっと調べないとな．自分の手元の環境以外の設定はちょっとどうなってるか判らないから．current version の方は eudev に入れ換えたり，llvm を入れ換えたりしてるから release version 以上にボロボロになってるので仕方なし．少しだけ current の 32bit 環境を調整したら，これまで Vega ではダメダメだった 32bit のコンソールが amdgpu を読み込む形で動作するようになりました．これまでは仕方ないから nomodeset で立ち上げてたから，少し進歩かな．

ざっとそんな感じ．追々，linux の方の詳細は調べて調整していきます．

Ryzen 5 2400G に内蔵されている Vega がもったいない気もするけど，まぁ，切り替えれば Vega/RX 両方の動作チェックに使えるかなぁと．

あと，Nvidia のカードに比べて RX の方が消費電力は大きいみたいだけど，MSI の GTX1060 8GB なカードに比べて動作音は静かな気もします．けど，使い方とか PC 筐体がが違うからあんまり比べても意味ないかな．GTX1060 はキューブ PC にいれて windows でゲームとか動画編集とかに使ってるけど，RX は普通の AT ケースで linux で使う感じだし．

まぁ，適当に使い分ける感じかな．

あまり参考にはならないかと思いますが，そんな感じ．

linux kernel の次の longterm support は kernel 4.19 になるって話なので，4.19.0 をビルド．

以前から utf-8 対応のコンソール日本語表示をするために gentoo 方面でメンテされている cjk パッチを使わせていただいていますが，4.18 系のものをそのまま 4.19 に使うと reject が出るみたい．ってことで手元のパッチを手作業で修正．

reject が出るところを見た感じ，なんか一部コードがオリジナルの方で対応されるように見えるなぁ．(イマイチ自信なしだけど...)

とりあえず，手作業で修正して日本語表示はざっとできることを確認したけど，時間のあるときにオリジナルの kernel の状況も調べておいた方がいいかもな．

画面表示はこんな感じ．ちょっと前の画面キャプチャーなので rc8 になってるけど．:-)

一応，4.19.x 用の cjk パッチは

https://github.com/qbilinux/qbilinux/blob/master/qbilinux/00_base/kernel/cjktty-kernel-4.19.patch
https://github.com/qbilinux/qbilinux/blob/master/qbilinux/00_base/kernel/cjktty-kernel-font-JP.patch

あたりに転がしています．cjktty-kernel-font-JP.patch に含まれるフォントは unicon のものになっています．

https://github.com/qbilinux/qbilinux/blob/master/qbilinux/00_base/kernel/cjktty-kernel.patch

の方は 4.18 用です．

https://github.com/qbilinux/qbilinux/blob/master/qbilinux/00_base/kernel/cjktty-kernel-font.patch

が cjk オリジナルフォント．

関連する config は FONT_16x16_CJK のあたりかな．

config FONT_16x16_CJK
        bool "console 16x16 CJK font ( cover BMP )" if FONTS
        depends on FRAMEBUFFER_CONSOLE
        depends on FB
        depends on VT_CONSOLE
        select CONSOLE_TRANSLATIONS
        help
          This is a high resolution console font that covers UNICODE bmp, 
          mostly is CJK font. If you want full UNICODE support on the VT console, say Y.

簡単だけど，そんな感じ．

ぼちぼちと Plamo Linux 6.x のソース一式を修正して，qbilinux という linux ディストリビューションを作成．

いつまで続くのか．

いじってる qbilinux のビルドスクリプトは https://github.com/qblinux/qbilinux，バイナリは https://qbilinux.org/pub/ にあります．

一応，Plamo Linux とは別もので，私個人が作っているものになります．はい．

aarch64 用の環境を作成していましたが，udev まわりがコンパイルが通らずにダメダメでした．仕方ないので，x86_64 の方で udev から eudev への差し換えを行なっていましたが，基本部分は終了．ということで，再び aarch64 の調整．

udev から eudev に差し替えるために作り直したパッケージを arm 64bit 環境の方でも作り直し．その後，インストーラーを適当にでっち上げて，インストール用の SD カードイメージを作成して新規インストールをトライ．

....

無事，ラズパイ3で純粋な arm 64bit 環境が立ち上がりました．キーボードとかネットワーク I/F も認識．一部のパッケージがうまく作れていなかったり，インストーラが一部こけたりしたので少しだけ手作業で修正した部分もありますが，まぁ許容範囲．この環境でいくつかパッケージを作成してみましたが，コンパイルエラーも無く普通に txz が出来上がることは確認しました．ということでベースとなる環境としては十分かな．パッケージ管理コマンド辺りがエラーでこけるけど，まぁ，追々調整する感じで．ただ，まだカーネルは debian 上のクロス環境で作成したものを使っていますけどね．

とりあえず，chroot 環境でエラーになってコンパイルが通らなかったもの (コンパイルに /dev 以下が必要な物とか...) をビルドしてから，この環境でコンパイラーなどから徐々にパッケージを作り直すって手順になるかと思います．

...な感じで行えば，綺麗な arm 64bit 用のパッケージが出来上がるかと，

一応，作業途中のファイルになりますが arm 64bit 用に修正したファイルを aarch64 というブランチを切って github に push しておきました．パッケージバイナリは基本的には https://qbilinux.org/pub/qbilinux-current/aarch64/ 以下の物を使っていますが，この状態から udev を削除して，代わりに eudev に入れ換えて，udev ライブラリをリンクしていたパッケージをリビルドしたようなものを使っています．後ほど，気が向いたらその状態にまで更新しておきます．

作ってる途中はカオス状態でしたが，新しい環境が徐々にきれいになってくると嬉しくなりますね．:-)

ただの日記です．:-)

少し前に「debian testing を Thinkpad に入れてみたけど，常用にはまだまだな感じ」って書きました．

debian testing から stable に戻したけど，やっぱり新しいアプリを手間を書けずに使いたい．

ということで，debian testing base でつくられてる ubuntu を試しにいれてみました．

過去，何度も ubuntu はトライしてみたんだけど，ユーザー環境として使うには何となく肌に会わなかったんだよな．デフォルトデスクトップの環境回りとか，ユーザー設定まわりとか．サーバーとしてはたまに使ってるけどね．

今回はサーバーとして使うのではなく，デスクトップ環境として使う予定なので 18.10 を選択．できるだけ新しいツール類を追い掛けたいので，通常リリースの最新版を選びました．サーバーとして使うなら LTS を選んだ方が良いかと思います．

で，ブート用の USB メモリをつくって Thinkpad X250 にさくっとインストール．

デフォルトのまま少しいじってみたけど，けどやっぱりそのままの環境は私には肌に会わないなぁ．単に私の考え方が古いだけかも知れないけどね．:-)

過去に試していたときにはそれで debian に戻っていましたが，今回はちょっとまともに設定をしてみることに．

root 環境は sudo を使うのではなく，普通に su する形に変更．root のパスワードを設定したり，sudo できないようにしたりとか．

デスクトップ環境はデフォルトのものではなく，わりと使い慣れている lxqt をインストール．

ほかに使い慣れているツール類を適当にパッケージからインストール．ついでに wnn7 も．ちなみに wnn7 のインストール方法は過去の blog に書いた「Ubuntu 15.10 に Wnn7 をインストール」と同じ方法で問題なくできました．はい．

あとは debian で使っている設定ファイルなどを適宜コピー．同じ debian 系列ってことで，環境コピーなどは割と簡単ですね．

な感じでカスタマイズ．

ようやく debian と同じ雰囲気で使えるようになりました．

細かいところとかはやっぱり違うけど，まぁ，そのうち慣れるかなぁと．もしくはちょっと気になるようならさらにカスタマイズすれば良いかな．たとえばフォント回りとか...．

それにしても，やっぱりディストリビューション側で新しいツール類が用意されているのは便利ですね．セキュリティアップデートなども簡単だし．

自分なりにカスタマイズしたことで割と便利に使えているので，しばらく ubuntu を使って生活してみようかなぁと思っています．

ぼちぼちと Plamo Linux 6.x のソース一式を修正して，qbilinux という linux ディストリビューションを作成．

いつまで続くのか．

いじってる qbilinux のビルドスクリプトは https://github.com/qblinux/qbilinux，バイナリは https://qbilinux.org/pub/ にあります．

一応，Plamo Linux とは別もので，私個人が作っているものになります．はい．

相変わらず aarch64 用のパッケージを作成中．

コンパイルに時間がかかるのでなかなか捗りませんね．llvm とかはコンパイルに数日かかってます．はい．

そんな感じですが，ざっと SD カード用の動作イメージをつくってみました．イメージは https://qbilinux.org/pub/isos-current/qbilinux-0.3_20181116_aarch64_sd.img.xz にあります．

イメージ自体は新規インストールをした直後の状態になっています．xz で解凍して，そのまま dd コマンドなどで 16G SD カードに書き込めば動作するはずです．root パスワードは設定していません．

ただ，私の開発環境用 (ラズパイ3 + 5inch 液晶 LCD5Pi) になっているので環境によっては画面表示がおかしくなるかもしれません．その場合には fat パーティションにある config.txt 中の

hdmi_group=2
hdmi_mode=87
hdmi_drive=1
hdmi_cvt=800 480 60 6 0 0 0
dtoverlay=ads7846,cs=1,penirq=25,penirq_pull=2,speed=50000,keep_vref_on=0,swapxy=0,pmax=255,xohms=150,xmin=200,xmax=3900,ymin=200,ymax=3900

あたりをコメントアウトするか，適当に調整してください．

もう一点．

イメージ自体は新規インストール直後の状態ですが，インストーラの文字化けのせいできちんとインストーラーからシステム設定ができていません．/etc の下のファイルを適当に設定しないといろんな不都合があると思いますので，このイメージを使われる方はその辺りの調整は自分で行ってください．_o_

/etc/rc.d/rc.inet1 中のネットワーク設定とか，/etc/ld.so.conf や /etc/nsswitch.conf の作成とか...かな？

開発ツールまわりは一通り作ってあるつもりなので，この状態でツールのコンパイルはできるかと思います．

また，デフォルトでは SD カードの ext4 パーティションにある実行イメージが立ちがりますが，fat パーティションの config.txt.inst を config.txt に，cmdline.txt.inst を cmdline.txt にコピーすればインストーラーの動作モードになります．この状態で立ち上げて root でログイン後，setup コマンドを実行すればインストール画面になります．ただし，インストーラー回りはまだ調整していないので完全に文字化け状態になっています．UTF-8 コンソールだけど，インストーラは EUC になっています．

まぁ，そんな感じのものですが，少しつづ進んではいますってことで，興味のある方はどうぞ．

一応，収録パッケージ一式は https://qbilinux.org/pub/qbilinux-current/aarch64/ にあります．

そんな感じかな．

最近，あまり blog 記事を書いていないのでただの雑談でも...．:-)

少し前に「久しぶりに ubuntu (18.10) をいじってみた」って書きました．

けど，結局 debian に戻してしまいました．

何でかって？

やっぱりいくら調整しても何か雰囲気がしっくりこない感じ．しかも何だか不安定．

しかも emacs が core dump してどうしようもない状態になってしまったのがトドメの一発．

apt で入れ直しても同じ．elisp も自分で入れたのではなく，全部パッケージ．

なのにダメ．

マシンを再起動してもダメ．

emacs が動かないと全く作業にならない．

しばらくは問題なく動作していたのに，何も設定変更をした記憶がないんだけど，ある日突然全くダメになってしまいました...．

え...，もしかして自分で修正するの？自作パッケージつくったりして？って思った瞬間，無理ーって思って debian に戻しました．正確には「無理ー」って言うよりも，そこまで手間をかけるなら，良く知ってる & 使い慣れてる debian に戻して自分で個別に入れているアプリの面倒を見る方がまだ良いかなって．

結局，デスクトップ環境としての ubuntu 生活は2週間ほどでした...．

同じ debain 派生とは言っても，ubuntu って何か独自の雰囲気がありますよね．

良いところ，悪いところいろいろあるけど．個人的には

良いところは最新バージョンを追っ掛けてればわりと最新ソフトが使えるってところ，

悪いところ何だかちょっと不安定で，バージョンごとにわりとデフォルト環境がコロコロ変わるってところ，

かなと思っています．個人的な感想なので間違っていたら，ごめんなさい．＞ ubuntu 関係者の方々．

あとは，ちょっと ubuntu-report が気持悪いかなってのもあります．情報収集したい気持はわからなくはないんですけど，やっぱり個人的には生理的に拒否反応が出てしまいます．前述の emacs がクラッシュした場合にも，「クラッシュ状況のログを送りますか？」っていうウインドウが立ち上がります．送られるレポートの中身を見ると，結構細かいことを送ってるみたいなので，これを送ってまで対応してもらうのはちょっと...ってなってしまうのでやっぱりパスって感じかなぁ．開発側は状況わからないと対応できないってのがあるとは思いますが，使う側としてはあんまり情報は出したくないかな．ubuntu-report に関してはいろいろ書かれている記事などがあるようなので，興味のある方は探してみてください．

ちなみに私自身が関係している Plamo Linux とか，自分でこねくり回してる qbilinux とかは個人用のデスクトップ環境に使ってるくらいですね．あんまり安定してなくても良いけど，わりと新しめのものが使いたい環境として使ってます．自分でなんでもいじり倒せるので，最新版が使いたいなと思えば自分でパッケージを作って差し換えれば良いので，気軽な感じで使えるところが良いかな．その分，不安定になりがちなんだけど．:-)

で，お仕事環境とかいろんな作業の時には OS が不安定だと困るし，サードパーティ製のアプリがきちんと動作する必要のあるので debian を使ってる感じです．この環境を今回 ubuntu で置き換えようとしたけどやっぱり debian に戻したってこと．ふと思い返すと，私自身 debian を使い始めたのは bo あたりからなので，なんだかんだと約20年くらい使ってることになるのかな．

参考までに Plamo Linux の開発者メンバーの様子を見てるとなんだか Arch が人気みたい．Plamo の設定自体も Arch を参考につくられている部分もあるみたい．「みたい」って書き方してますが，私自身は Arch って触ったことないんですよ．インストールマニュアルをちらっと見てちょっと面倒だなぁと感じてそれっきり．各種ドキュメントの方は非常に良くできてるので，ちょくちょくお世話になっていますけど．:-)

ほかには gentoo とかもありますけど，こっちも触ったことありません．ごめんなさい．

結局，私自身が linux をさわり始めた初期に debian と plamo / slackware に出会ってから，わりとこれらに満足してからそれ以外にはあんまり手を出していないってのが実情です．redhat 系は必要に迫られて仕方なくって感じで使うことはあるけどその程度．

linux のほかに BSD 系もありますけど...

最初に PC UNIX を使い始めたのきっかけは 386BSD(98) から．友人が開発に関わってたので開発版のフロッピーが手軽に入手できたんですよね．そこから，FreeBSD / NetBSD まではわりとがっつりいじってましたが，その辺りで linux に浮気(?)して，それ以降はあまり使ってないかなぁ...って感じ．その linux に移行したのが丁度 debian bo くらいの時期でした．サーバーに BSD 系 OS が使われていることがあるので，いまでもたまにユーザーとして *BSD は触ることはありますけど，まぁ，その程度な感じですね．

最近でも自分で立ち上げるサーバーに BSD を使いたいなと思うことがたまにあって，評価がてら少しインストールして触ってみたりしますが，使いたい市販ソフトが BSD に対応してなかったり，その他いろいろな事情で，実際に立ち上げたことはないかなぁ．同じように，ソフトが対応していないってことで BSD をデスクトップ環境としても使ってないですね．linux エミュレーションを使ってまでやるなら linux でいいやって思っちゃうので．

...

Solaris が無料配布に切り替わったころに，intel マシンに Solaris を入れて使っていたこともあったなぁ．

そういえば，かなり昔，Ultra SPARC なマシンをウチに置いて，Solaris をインストールしてサーバーとして使っていたこともありました．Wnn が標準添付されていたし，画面やフォント表示とかもきれいだし，キーボードも使いやすかったです．intel CPU の載った拡張ボードもつけて，SPARC Solaris の上で intel な環境の MS Windows が Solaris のウインドウ環境で動作するようにセットアップもしました．...けど，あまりの騒音に耐えかねて数ヵ月で処分してしまったかな．そのときに WS はウチに置くものではないなとちょっと痛感．あんまり記憶が定かじゃないんだけど，機種は Ultra5 あたりだったかなぁ．通称ビザボックスね．:-)

話戻して...

それにしても OS には一長一短あるから，まぁ，自分に合うもの & 用途に合うものを探していじるのが良いのではないかと思います．

BSD とか GPL とかライセンス形態の違いも色々ありますからね．

まぁ，linux の話から始まって，思うままに昔話も含めてだらだら書いてみましたが，そんな感じで色々使ってます．はい．

ぼちぼちと Plamo Linux 6.x のソース一式を修正して，qbilinux という linux ディストリビューションを作成．

いつまで続くのか．

いじってる qbilinux のビルドスクリプトは https://github.com/qblinux/qbilinux，バイナリは https://qbilinux.org/pub/ にあります．

一応，Plamo Linux とは別もので，私個人が作っているものになります．はい．

前回までで aarch64 用のベースとなる開発環境を立ち上げたところまで作成．

さて，これからどうしようかと．

このまま aarch64 用のパッケージを作りつつ，インストーラーイメージを調整しようかと思ったんだけど...ちょっと色々あって思いとどまり．

現状の aarch64 用修正は暫定的に必要最小限だけ修正しています．これまで x86_64 の時だけ 64bit 対応になっているものを，aarch64 も 64bit 対応にしている形です．

以前，少し書きましたが，現状のビルドスクリプトの見通しが悪いので，記述方法を新しい形式に変更しようかなと思っています．しかし，このまま修正を続けても，その新しい形式に変更する際に再び大規模な修正をすることになってしまいます．ってことで，一旦，全体のビルドスクリプトを新しい書式に修正しようかなぁと．その方が新しいアーキに対応させるのも楽になりますので．

記述方法に関しては「Plamo Linux の野良パッケージ作成（その６６）: current の方のパッケージ更新」に少しだけ説明を書きましたが，共通部分を /usr/src/qbilinux/PackageBuild.* ファイルにまとめて記述して，それ以外を各パッケージのビルドスクリプトに記述する形にしようかなと思っています．ただ，まだ記述方法が試行錯誤な感じで書き方が揺らいでるけど，まぁとりあえず書いてみてそのあとで微調整しようかなぁと．

ということで，各パッケージのビルドスクリプトを大幅修正中だったりします．地味に時間かかってますけどー．

とりあえず必要最低限な基本パッケージの修正が終わったら，インストーラーの調整をする予定にしています．年内中になんとか終われば良いんだけど，なんとかなるかなぁ．ちょっと微妙かなぁ．

まぁ，少しつづではありますけど，そんな感じで徐々に作業してるって感じです．

先日，「安かったのでいまさらながら Radeon RX570 なビデオカード入手」って書きました．

開発用につかっている Ryzen G マシンに Radeon RX カードを増設したって話ね．そのときには，Windows は全く問題なし．debian は何か問題ありそう．自作の linux 環境 (qbilinux) はコンソールは問題なさそうって書きました．
その後，すこしだけ色々試してみたのでその状況を少し書いてみます．現状，いろんな問題があるので完全に解決してからこの文章は書こうかなと思っていましたが，なんだかあまり時間がなくって試すのが遅くなりそうなので，とりあえず現状わかっている範囲だけで書きます．

まず，debian．

Ryzen G だけで動作していた環境に RX570 を差したら画面表示できません．グラボの自動判別ができていないのかな？なぜかリモートからもログインできないので，仕方ないので新規インストールしてみようかなと思って stable のインストーラーでブートしたらダメ．仕方ないので testing のインストーラー持ってきて試してみたけどそっちもダメ．画面が表示できない状態です．

ってことで，現状の debian のデフォルトでは Ryzen G + Radeon RX はダメみたい．intel みたく，CPU 内蔵グラフィックとグラボが同居することは考えられていないのかな？それとも同じ amdgpu を使う形なのでダメダメになっているのか．現状そのくらいしか試していないですが，時間のあるときに追っ掛けようかなとは思っています．

次，自作の linux ディストリ．qbilinux って名前で作ってるものね．

64bit の方は開発がてら調整してみました．コンソール表示も X も問題なく表示できます．X は自動認識ではなく，昔ながらの xorg.conf を作る形になってますので，ここで調整すれば問題なし．コマンドラインから

$ lspci -v

すると

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480] (rev ef)

な感じで表示されますので，これを xorg.conf に書くだけ．

Section "Device"
    Identifier "Card0"
    Driver "amdgpu"
    Option "DefaultDepth" "24"
    BusID "PCI:1:0:0"
EndSection

な感じかな．普通に KDE とかも使えてます．はい．

最近はこの環境で作業しています．:-)

32bit の方はまだ調整・確認等は行っていません．普通に動くと良いんだけど...．

まぁ，デフォルトのままだと debian ではあれっぽいけど，まぁ Ryzen G + Radeon RX という組み合わせで linux でも普通に使えるということで．

ちなみに上記以外のディストリで動作確認をする予定はありません．_o_

あんまりこういう構成で使っている人は少ないかも知れませんが，参考までに．

前回「Ryzen G + Radeon RX な環境での linux GUI 動作確認 (途中)」の続き．

Ryzen 5 2400 G に Radeon RX570 なカードを増設してみたところ，debian で動作しないって書きましたが，その後，debian で色々試してみてなんとか動作したのでその顛末を．

まず，動作しなくなった debian stable の状況を確認．

とりあえず xdm を立ち上げないで様子をみてみる．

別パーティションの linux から debian のパーティションを /mnt にマウントして

$ vi /mnt/etc/X11/default-display-manager

で，使っている xdm をコメントアウト．

たちあげてみたけどやっぱりダメ．ブラックアウトしたままだんまり．

X に制御が遷移する前にダメになってるみたいだね．コンソール表示のために amdgpu を読んだ後にダメになってるのかな．

ということなので，その amdgpu を読み込まないように細工．

$ vi /mnt/e/mnt/etc/modprobe.d/blacklist.conf

で新しいファイルを作成して

blacklist amdgpu

と記述．

立ち上げてみたところ，login プロンプトまでは到達．

でも，USB キーボードが効かないね．

ブート途中でも usb モジュールがどうのってメッセージが流れていたから usb 関連モジュールがロードできてないみたい．

グラボの増設とは全く関係ないと思うんだけど，ちょっと不思議．

うーむ．

次，log ファイルの確認．/var/log/kern.log を確認．

ACPI BIOS Error は出てるけど，これは普段使ってる linux 環境の方でも出てるので無視しても問題なさそう．

あと，xhci_hcd 関連でエラーが出てるね．

xhci_hcd 0000:02:00.0: Error while assigning device slot ID
xhci_hcd 0000:02:00.0: Max number of devices this xHCI host supports is 127.
usb usb1-port9: couldn't allocate usb_device
xhci_hcd 0000:02:00.0: Error while assigning device slot ID
xhci_hcd 0000:02:00.0: Max number of devices this xHCI host supports is 127.
usb usb1-port10: couldn't allocate usb_device

な感じ．なぜ？ちょっと不思議．

カーネル差し換えとかしないとダメなのかなぁとちょっと思い始め．

目線を変えるために，ubuntu ではどうなるのかなと少しトライ．ubuntu 18.10 の iso で立ち上げてみたところ，グラフィック画面は表示されました．が，しばらくするとこけました．xhci_hcd 関連でエラーが出てるのは debian 同様．

この状態をみると xhci_hcd エラーと画面が表示できないのは別々の問題らしい．

でも，ubuntu がまがりなりにもグラフィック画面まで表示できるってことは，debian buster (testing) を使えば何とかなるのかなぁ？と．

このマシンの debian 環境はあまり安定性は求めてないので，とりあえず debian testing を入れてみることに．

以前は，testing の最新の iso を使っていましたが，見当たらなかったので firmware-buster-DI-alpha3-amd64-netinst.iso を使ってみました．一応，firmware の iso を使いました．

前回，グラフィックインストーラーを選択したところダメダメだったので，安全を考えてコンソールインストーラを選択したところ，普通にインストーラーが立ち上がりました．キーボード操作も問題なし．

この状態から必要最小限の環境でインストール．その後，再起動．

問題なく debian testing が立ち上がりました．ふう．

次，グラフィックが動作するか確認．

その環境に X をインストール．

$ apt-get install xorg twm

くらいかな．最初，tasksel から gnome を入れてみようとしたら，途中でこけたので手動で最低限の X 環境をインストール．tasksel が途中でこけることは testing ではよくあること．

で，root でログインして startx．

普通にグラフィックス表示できました．ふう．

ちなみに kernel は 4.16.0-2 (4.16.12-1)．

その後，firmware-amd-grahics をインストールすれば，コンソールも高解像度になりました．

ここまでは良かった．

けど，kernel をアップデートして 4.18.0-3 にしたところダメダメに．

手元の stable がダメダメだったのはこのせいかも．backports の 4.18.x を入れていたからなぁ．また，前回，testing のブートでダメダメだったのは testing の最新 iso を使っていたせいかもしれません．もしかしたら，最新 iso のカーネルが 4.18 系列だったのかも．

でもまぁとりあえず testing で kernel 4.16.x を使えば問題なく使えているのでその形でしばらく使っていこうかと思います．

結構，時間がかかりましたがそんな感じで (一応) 解決．

けど，この問題が buster (testing) がリリースされるまでに解決しないとちょっと悲しいことになるなぁ．何か報告した方が良いのかなと少し思ってたり．

簡単ですが，そんな感じ．

最近，ラズパイ用の steam link ソフトがリリースされています．現状，beta 版という扱いですけど，詳細は https://store.steampowered.com/ の「コミュニティ」＞「スレッド」から raspberry pi で検索してみてください．

製品版のハードウエアの steam link が販売されていましたが，販売終了になったみたいで，かわりにラズパイを使ったソフトを出したって事なのかな？

あ，steam link とは PC の steam の画面を転送して，テレビとかで表示するためのものです．単体で steam が動作する物ではなく，PC でベースとなる steam を起動させておく必要があります．

手元に，製品版の steam link もありますが，ラズパイもあるので試しにインストールして軽く比較してみました．

使ったラズパイは Raspberry Pi 3 Model B です．

上記，URL の指示通り，普通に rasbian stretch が入った環境を用意．一応，stretch は最新までアップデートしました．で，ターミナルを開いて

% wget http://media.steampowered.com/steamlink/rpi/steamlink_1.0.7_armhf.deb

で deb ファイルをダウンロード．最初，サイズが 33k しかなくってダウンロードに失敗したかと思ったら，これで合ってたんですね．サイズが思ったより小さくて驚き．

% dpkg -i steamlink_1.0.7_armhf.deb

でインストール．

メニューに steam link のショートカットが追加されるので，そこから起動．

beta ですけど普通に動きました．

最初の起動時に製品版の steam link と同様に，PC とのリンク作業が必要になります．steam link からリンクしたい PC を選択して表示されるキーコードを PC 側で入力するって形です．

そこから色々設定しますが，途中の画面は...色々プライベートなことも表示されているので省略．設定終了後，shadow of the tomb raider を起動してみました．

動いたー．けど，なんかフレームレートが残念な感じ．手元の環境だとパラパラ漫画程度．この状態ではゲームしたくないなぁという感じ．ラズパイだからかな？と思ったけど，ハードウエアの steam link で試してみたところ同じ感じなのでラズパイだからってのは関係ないみたい．

ためしに steam link の設定を少しだけいじってみたけどあんまり変わらない．

PC 側の設定を調整すればもう少しましになるかもしれないですけど，そこまでは確認していません．ちなみに PC 側の画面はなめらかに表示されていました．shadow of tomb raider 自体がわりと重たいソフトなので，そうなってしまうのかな？それとも PC 画面を割と高解像度に設定しているからなのかな？ちょっと原因は不明だけど，PC 側の設定で解像度を下げれば軽くはなりそうな気がしています．

じゃあてことで，軽い物だとどうなるかなと思って beyonetta を起動．

こっちはなめらかに動作しますね．これなら普通にゲームするのも問題ない感じ．

次，FF13．

これも問題なし．

やっぱり PC 側の解像度設定の問題かなぁ？beyonetta とか FF13 は FHD モニターを使っていた頃にやっていたゲームだけど，shadow of tomb raider の解像度は WQHD (2560x1440) に設定していた気がするからなぁ．

まぁ，時間があるときに気が向いたら設定変更してもう少し試してみようかなとは思います．

あ，書き忘れてましたが，音声も問題なくラズパイの HDMI 端子から出力されていました．XBOX 360 のコントローラーを使っていますが，それも問題なく動作．というか，steam link なのでキーボード・マウスではなくコントローラーが必須みたいな感じです．初期設定時にキーボード・マウスしかつないでいないとコントローラがないよって怒られました．

これならハードウエアの steam link の代わりにラズパイでも良いかなって出来ですね．普通に比べてみても遜色ない感じです．ただし，使い勝手はハードウエアの方がやっぱり専用機だけ有って使いやすいです．はい．

私の場合，steam link は 2000円 くらいで販売されていたときに購入したから，わざわざラズパイを使う意味は無いかもしれないけどね．ラズパイの方が全然値段は高いですから．参考までに steam link を購入したときの blog 記事は「Steam Link を購入してみました」あたりに書いてます．

手元にラズパイがあって，かつ，ある程度ラズパイの知識があって，いまから steam link を試してみたいって場合には気軽に試せるので良いのではないかなぁと思います．ハードの steam link が壊れたときの代替としても使えるかな．

簡単ですけど，そんな感じです．

マルチメディアプレーヤーソフトの kodi もそろそろ 18.0 リリースが近づいてきた感じですね．

現状，18.0rc2 が最新かな．

ということで動作確認してみました．

linux 上で自分でビルド．qbilinux って名前で作ってる自作ディストリビューションを使ってます．

問題なくビルドも通り，普通に動作してる感じ．

ついでに pvr.chinachu もビルド．

pvr.chinachu は kodi 上から chinachu をコントロールしてテレビや録画を見えるようにするアドオンです．

master は 17.x 用になっていますので，18.0 用に開発されているブランチを取得．https://github.com/Harekaze/pvr.chinachu/tree/18.x-Leia のあたりです．

zip をダウンロードするなり，git clone するなりでソースを取得して，ドキュメント通り

$ ./bootstrap
$ ./configure
$ make

でブラグイン作成．

kodi のアドオン追加画面から zip ファイルを追加を選択して，できあがった pvr.chinachu.zip を読み込み．

あとはプラグインの設定などを実施．

pvr.chianchu などの細かい設定方法は，過去の blog を探してみてください．あんまり詳しくは書いてないけど「いまさらながら debian の kodi に pvr.chinachu を導入」のあたりとかかな．

普通に録画やテレビなども表示できました．

ふむふむ．

少し前に試していた rc1 では若干表示が崩れることがあったけど，rc2 ではその症状もあまりなくなった感じ．詳細に差分はチェックしてないけど．

とりあえず，kodi 18.0 系の動作報告でした．

参考までに，試している環境の qbilinux x86_64 版は https://qbilinux.org/pub/qbilinux-current/x86_64/ あたりに転がしてあって，ツリー上の kodi は現在は 18.0rc1 (http://qbilinux.org/pub/qbilinux-current/x86_64/contrib/Multimedia/kodi-18.0rc1-x86_64-T1.txz) とかになっています．が，ディストリビューションのインストール用 iso ファイルも作ってないし，まともなインストーラーもないのであんまり参考にはならないかもです．はい．

そのあたりの作業は追々おこないます．年内中に何とかと思ってたけど，ちょっと無理かな．

pvr.chinachu は GPLv3 みたいなので，次回 qblinux リリース時には同梱してしまおうかなぁ．

まぁ，こういったことを適当に＆気軽に試せるのが自作ディストリビューションの良いところ．

kodi の android 環境でのチェックなどは 18.0 がリリースされたら改めてやるつもりです．

簡単ですけど，そんな感じ．

ぼちぼちと Plamo Linux 6.x のソース一式を修正して，qbilinux という linux ディストリビューションを作成．

いつまで続くのか．

いじってる qbilinux のビルドスクリプトは https://github.com/qblinux/qbilinux，バイナリは https://qbilinux.org/pub/ にあります．

一応，Plamo Linux とは別もので，私個人が作っているものになります．はい．

ぼちぼちと x86/x86_64 環境でビルドスクリプトを更新しながら，その変更をラズパイ3の armv7l/aarch64 環境に取り込み中．

で，その際にラズパイ3上で armv7l 用と aarch64 用に同じパッケージを作成してます．

改めて同じ環境でビルドするとやっぱり 32bit 環境で使った方が早いね．

コンパイル時間が明らかに早い．

ラズパイのボードだとメモリが少ないのでやっぱり 64bit で使うよりも 32bit で使った方がよさそう．

ざっとパッケージビルド時のログとかをチェックすると，32bit の方が 10%〜15% くらい早い感じかなぁ．

heimdal のコンパイルが 32bit 環境で 32分 に対して，64bit 環境で 36分 くらい．他もそれくらいの差．

USB ハードディスク上に swap を取って作業しているので純粋な処理速度の差か本当にそれくらいあるかどうかは判らないけど，まぁそれくらいの差．

それを大きいと感じるか，小さいと感じるかは使う環境に依るかなとは思いますけど．

まぁ，趣味程度に作ってる物だし，64bit 環境は将来的に 64bit arm 環境で大きなメモリを積んだボードが出れば使えるかなぁと思いつつ作ってるので私の場合はいいんだけどね．

同じ事が x86/x86_64 でも言えると思います．

なので，手元の core2duo なマシンは 64bit 環境でも動作するけどメモリを 2G しか積んでないので 32bit 環境で使ってますね．はい．

以上，参考まで．

ぼちぼちと Plamo Linux 6.x のソース一式を修正して，qbilinux という linux ディストリビューションを作成．

いつまで続くのか．

いじってる qbilinux のビルドスクリプトは https://github.com/qbilinux/qbilinux，バイナリは https://qbilinux.org/pub/ にあります．

一応，Plamo Linux とは別もので，私個人が作っているものになります．はい．

相変わらずパッケージビルドスクリプトを更新中．

当初は基本パッケージのものだけ修正したらインストーラーの調整をしようと思っていましたが，途中で別の作業をするよりも一気に作業してしまった方が良さそうな感じがしたのでパッケージビルドスクリプトの修正作業を継続．

で，ひととおり書き換え作業自体は終了．新しい形式に全部(?)書き直しました．

バックアップがてら，ある程度デバッグしたものをここ数日で github の方に上げてしまいましたが，まだまともじゃない状態になっているので，現状の github ソースは使わない方が良いかと思います．持っていく人はほとんどいないと思いますが，一応，忠告を...．push したあとに別ブランチを切っておけばよかったかなとちょっと後悔しましたけど．

この状態でぼちぼちとデバッグ中．まともにビルドできるって確認したのは，まだ8割くらいかなぁ．

あたらしい形式ではソースファイルとビルドする場所をできるだけ分離しようとしていましたが，configure & make でコンパイルするツール類でもソースを分離してしまうとコンパイルが通らない物が結構な数ありますね．.h が見つからないというエラーで落ちるパターンが多いかな．ほかには Makefile 中から呼び出されているスクリプトなどがカレントにソースツリーがあることが前提になってるとか．エラーになる場合はこれまでどおりソース一式をコピーする形にしています．

また，configure でコンパイルするツール類で，ソースに同梱されている config.gess, config.sub が古すぎて aarch64-*-linux というアーキを自動認識できなくてエラーで落ちるパターンも多いです．当初はあたらしい config.gess, config.sub をビルドスクリプトに同梱する形で修正していましたが，あまりに同様のエラーで引っかかるものが多いのでどうしようかなぁと思案中．途中から pkgbuild パッケージ (https://github.com/qbilinux/qbilinux/tree/master/qbilinux/01_minimum/devel.txz/pkgbuild) にファイルを同梱してそれをコピーする形にしましたが，それでもかなりな手間と時間がかかってるので，ソース中に config.gess, config.sub が含まれている場合には強制的に全部上書きしてしまう形でも良いかなぁと考え中．けど，そうするとこれまでコンパイルした物も一応チェックする必要があるから，それも手間になるかなぁ．うーむ，悩みどころ．強制的に上書きするのはやっぱり危険だし，現状のままが良さそうかなぁ．

新しいビルドスクリプトのフォーマット詳細に関する説明は改めてどっかで書きますね．そういえば，各種ドキュメント等を置こうと思って立ち上げようとしてた web サイトの構築も放置してるなぁ...．

他に，Plamo Linux 6.x ではパッケージ分類が

00_base/
01_minimum/
02_x11/
03_xclassics/
04_xapps/
05_ext/
06_xfce/
07_kde/
08_tex/
09_kernel/
10_lof/
11_mate/
12_lxqt/

のようになされています．この意味ですが，数字の小さい物が数字の大きな物に依存するという形式になっています．たとえば 06_xfce に含まれるパッケージを使うためには 00 〜 05 のパッケージをインストールする必要があるといった形です．けど，これが問題なんですよね．現状では 06 のパッケージを入れていないと 05 が動作しないといった感じで，数字の大きな物を入れないと数字の小さな物まで動作しないというパッケージが相当数有ります．オプションライブラリ or オプションツールといった扱いではなく，それがないとコンパイル自体が通らないといった必須ツールでそういった感じになっている物が多いです．

パッケージのバージョンアップ途中でそうなってしまったのか，それとも元々そうなっていたのかは不明ですが，一旦そういったパッケージが紛れてしまうとそのパッケージを見つけるのに結構な工数がかかるんですよねぇ．

まぁ，Plamo Linux 6.x のツリーをそのまま流用している関係上，qbilinux 環境も同様の状態になっていますが，今のところはそのままにしています．けど，そのうちどうするか考えないとダメなのかなとは思っています．下手に数字分類を残すよりも，元々の Slackware のように数字分類を無くして，依存関係は自分である程度解決してね程度にしてしまうのも手かもしれないかなとは思っています．:-)

あと，ビルドスクリプトの修正の話とは直接関係ないですが，github の方に push するときに，ラズパイから直接作業したときに時刻設定をミスって，ファイルの更新日時が 1 Jan 1970 ってなってるものがボチボチあります．元々は ntp のパッケージングのバグが原因なんですけど，現在は修正したので今後は発生しないと思いますが，ちょっと恥ずかしいなぁと思っていたり．

まぁ，そんな感じでぼちぼちやってますが，年内中くらいにはビルドスクリプトの修正は終わらせて，インストーラの調整を始めたいなと思っています．はい．

ぼちぼちと Plamo Linux 6.x のソース一式を修正して，qbilinux という linux ディストリビューションを作成．

いつまで続くのか．

いじってる qbilinux のビルドスクリプトは https://github.com/qbilinux/qbilinux，バイナリは https://qbilinux.org/pub/ にあります．

前回の blog で「各種ドキュメント等を置こうと思って立ち上げようとしてた web サイトの構築も放置してるなぁ...」と書きましたが，放置してるのも何なのでやっつけで web サイトを立ち上げました．過去の blog を見返したら 9月頃に「作ったらアナウンスします...」と書いてましたね．失礼しました．

web サイトの URL は https://qbilinux.org/ になります．

けど，中身はなーんもありません．

web サイトの構築自体には CMS を使ってるので，気が向いたときに適当に情報を追記していこうかと思います．

とりあえず連絡まで．

QNAP の NAS を使っています．型番は TS-853Pro かな．

最近，HDD が手狭になってきたので，HDD を交換するか，外付けの USB HDD ユニットを増設するかなと思案．

で，調べてみたら，いつのまにかこれまで販売していた QNAP の NAS 用外付け USB HDD ユニットが販売終了みたい．

本体と USB 接続する HDD ケースで，5台 or 8台 の HDD を入れて RAID 構成にできるものですね．型番としては ux-800p とか ux-500p です．

QNAP のホームページから記載が消えていて，ux-800p の方は流通在庫はあるみたいだけど，ux-500p の方は流通在庫ももうないみたい．たまに見掛けても，製造終了を見越して，ふっかけてる値段をつけているものもある感じ．

どうしようかなぁと思ったら，代わりにあたらしい製品が追加されていますね．型番は TR-004．

QNAP NAS 以外に Windows PC/Mac などにも直接接続できるようになったみたい．

値段はいくらかなぁと思い，QNAP といえば oliospec かなということで http://www.oliospec.com/ をチェック．

あれ？12/22 に oliospec で発表会をやったばかりの新製品だったみたいだね．

値段は 税込31,104円（税抜28,800円）か．割とリーズナブルかもな．

注文してみるかなぁ．

ちょっと考え中．