Posts

Showing posts from February, 2017

Chromium for NetBSD

https://svnweb.freebsd.org/ports?view=revision&revision=433722によると、Chromiumでsegfaultする場合があるのは、このパッチで直るようだ。早速試してみる。 追記: と思ったが、どれも既に適用済みだった。やっぱり57まで待つしかないかな。

journal.mycom.co.jp

http://journal.mycom.co.jp/がなくなってから、http://news.mynavi.jp/へ、随分と長くリダイレクトされていたのだが、さきほど見たらリダイレクトされなくなっていた。

Chromium for NetBSD

Chromium 56.0.2924.87 (pkgsrc/wip/chromium-new)では、 Gentoo Linuxのフォーラムにあるのと同じように、 gmailやGoogle Calendar、Amazon.co.jp等でsegfaultしてしまい、使えない。 とりあえず57がリリースされたらまた試してみることにする。

Chromium for NetBSD

Chromium 56をNetBSDで動かそうとしているのだが、 Google Calendarやgmailだとページの描画が終わった瞬間に何かがsegfaultして クラッシュ時のインフォメーションページに移行してしまい、 使うことができない。 デバッグビルドをしようとすると、8GB RAM+16GBスワップでもリンク段階で メモリーを使い果たしてしまう。 どこがいけないのか…。

cramfsの話

NetBSDでのファイルシステムの扱いについて理解したいと考えているのだが、 いろいろなことが分からなくて、先に進まない。 そこで、既存の簡単なファイルシステムのサポートをNetBSDに追加してみることで 学習したいと考えている。 Linuxで最も簡単なファイルシステムは、cramfs (Compressed ROM file system) と言うものであるように見える。 なんで、Compressed ROM file systsmがcramfs と略されるのかというのは疑問ではあるが…。 とりあえず、既存のリトルエンディアンなcramfsのディスクイメージを 手元で作れるようにした。単にSUSE 13.1のutil-linux-2.23.2-34.1.x86_64.rpmを 展開し、NetBSD/amd64のcompat_linuxで動かしただけである。 ドキュメントがgnu-gpl-v2なソースコードを見ろとだけ書いてあって 困っているのだが、基本的には生成されたディスクイメージを見て、 パースするプログラムを書いている。 NetBSDカーネルでサポートする際にも、このコードは役立つものと考えている。 今のところ、ユーザーランドのプログラムであるパーザーでは、 Super blockとinodeをパースできるようにはなった。 後はzlib deflateで圧縮されたファイル本体のデータの取り扱いが できるようになれば良い。 今、イメージできないのは、zlibで圧縮されたデータをいつ展開するか と言う問題である。 例えば、これにはディスクイメージのマウント時に全てをRAMに展開しておく 方法と、個々のファイルにアクセスした際に展開する方法があると思う。 ユーザーランドのパーザーとしては、mmap(3)でイメージファイルを RAMのある範囲に割り当ててパースしてやれば良いのだが、 そもそもこう言う場合のNetBSDカーネルの流儀と言うのが分からない。 コマンドラインのユーティリティープログラムとしては、mount_cramfsと makefsでリトルエンディアンとビッグエンディアンの両方のディスクイメージを 作れるようにして置けば十分であろう。

Chromium for NetBSD

FreeBSD Portsのwww/chromiumに含まれているパッチをベースに、 pkgsrc/wip/chromium-newで作業をしているのだが、 なかなかNetBSD向けのパッチをマージし切れないでいる。 だが、目新しいことはないので、時間はかかるがやって行けば良さそうだ。 FreeBSD Portsのパッチでは、is_bsdやtarget_os='bsd'という記載が あるのだが、これは、is_freebsdやtarget_os='freebsd'とでもしておかないと NetBSD向けにうまく分岐を作れない場合がある。 これについては、FreeBSD PortsのパッチがChromiumのupstreamに 提出されているかどうかを調査して、あるとしたらそれにコメントを付けないと いけないのだが、なかなか腰が上がらない。 特に、CLA (Contributor License Agreement)に同意するハードルが高い。 でも、ここはどうにかして、先に進みたい。

Chromium for NetBSD/amd64-current

pkgsrc/wip/chromium-newとして、時折Chromium web browserをNetBSD/amd64-currentで動かせるように試している。 しかし、オーディオの再生ができないので、pkgsrc/www/chromiumとしてインポートすることはできないと考えていた。 だが、もしかしたら、これはaudio/alsa-plugins-ossがfloatで出力しようとして、OSSが受け入れられずに音が出ないという pkgsrc/www/firefoxと同じような問題なのかもしれないと言う気がして来た。 と言うことで、chromium-56.0.2924.87をビルドしてみることにした。

qemuのhppa (HP PA-RISC)サポートとNios IIサポート

久しぶりにqemuのツリーをpullしてみると、 target/hppatarget/nios2 と言うのが追加されていた。 ちょっと見ただけだが、いずれもMMUも実装する方向ではあるようだ。 2017-02-13現在では、qemu-system-nios2はビルドされるが、hppaはまだツリーにあるだけのようだ。 $ qemu-system-nios2 -cpu ? (何も返ってこない) $ qemu-system-nios2 -M ? Supported machines are: 10m50-ghrd Altera 10M50 GHRD Nios II design (default) none empty machine また、qemuのウェブサイトも 新しくなっている

Redmineをサブディレクトリーで運用する

RedmineというIssue Tracking Systemがある。 多機能であるが使いやすく、ソフトウェア開発以外でも使えるので、 便利に使わせてもらっている。 pkgsrcだと、pkgsrc/deve/ruby-redmineに収録されている。この記事の適用されるバージョンは、3.3.2である。 これはこれで、改善すべき点が山ほどあるパッケージなのだが、 とりあえず手軽に動かすと言うだけであれば、使えるものではある。 pkgsrc/devel/ruby-redmineでは、 標準ではunicornというアプリケーションサーバーで動かすことができるようになっている。 だが、標準ではあくまで、ルートディレクトリーで動かすような設定となっている。 だが、このようなサービスは、HTTPSで運用すべきであるし、 そうなると、サーバー証明書を取得するコストも考えると、 他のサービスと共有されたサーバー上で運用されることとなる。 一番簡単なのは、サブディレクトリーにアクセスすると、 Redmineを使用できるという運用である。 つまり、https://www.example.com/redmine/にアクセスすると 使用できると言うことである。 この時、https://www.example.com/nextcloud/にアクセスすると Nextcloudが動いていると言った状態である。 設定内容 変更すべきは3箇所である。 /usr/pkg/share/examples/rc.d/redmine_unicorn22からコピーされた/etc/rc.d/redmine_unicorn22 (ここで22はRuby 2.2を使っていることを示している。)/usr/pkg/share/ruby22-redmine/app/config.ru/usr/pkg/share/ruby22-redmine/app/config/environment.rb/etc/rc.d/redmine_unicorn22への変更 RAILS_RELATIVE_URL_ROOT='/redmine'をunicornの起動の際の環境変数に追加する。 $ diff -u /usr/pkg/share/examples/rc.d/redmine_unicorn22 /etc/rc.d…

eCosの動き

eCos (Embedded Configurable Operating System)に興味があるのだが、 公式にはもうしばらくリリースはされていないし、 CVSリポジトリーへのコミットもされていない。 eCosのbugzillaは、ユーザー登録が必要であるが、それを見ていると 時折バグや機能拡張は報告されている。 bugzillaにあるものは、ある意味bugzillaにまとまっていると言えるので、 それ以外に公開されているeCosに関するソースコードについて、 リンク集的にまとめておく。 ZPU CPU supportZynq (ARM core for FPGA) supportPort of sqlite3, spidermonkey and eCos improvementslibpng, jpeg and some HALs