nDiki : ソースパッケージ
ソースパッケージ - source package
2001年5月8日 (火)
Zebedee で念願の secure connection 達成
とあるサーバへの接続(pop, telnet, ftp)がセキュアではないのでずっと不安なのだが、ルート権限がないので sshd も動かせない。 以前 sshd を一般ユーザで動かそうとしたのだが、その時は失敗。
今回 Zebedee を知ったので試してみることにした。Zebedee はフリーのセキュアなトンネルプログラム。 設定無しで動く/Windows上でも動く/通信の圧縮あり/特許問題なし/GPLあたりが特長。
Debian GNU/Linux ではまだパッケージ化されていないようなのでソースからビルド。 インストールに必要なライブラリも一応一緒に作ることにする(Zebedee の Makefile が Zebedeeアーカイブをを展開先の親ディレクトリに各ライブララリパッケージを展開してある事を前提としているので、その方が楽)。
Zebedee のサイトからソースパッケージと必要なライブラリ(zebedee-2.2.1.tar.gz, blowfish-0.9.5a.tar.gz, zlib-1.1.3.tar.gz, bzip2-1.0.1.tar.gz を作業ディレクトリにとってくる。
ビルドする環境は Debian GNU/Linux、インストール先を /usr/localzebedee-2.2.1 とする。
$tar zxvf blowfish-0.9.5a.tar.gz $cd blowfish-0.9.5a $make optimize $cd .. $tar zxvf zlib-1.1.3.tar.gz $cd zlib-1.1.3 $./configure $make $cd .. $tar zxvf bzip2-1.0.1.tar.gz $cd bzip2-1.0.1 $make $cd .. $tar zxvf zebedee-2.2.1.tar.gz $cd zebedee-2.2.1 $make OS=linux $make install OS=linux ROOTDIR=/usr/local/zebedee-2.2.1 $cd doc_jp $make $make install ROOTDIR=/usr/local/zebedee-2.2.1
でインストール終了。ローカルでテストしてみる。
zebedee -s でサーバを起動。 telnet サーバをたちあげていないので smtp にトンネリングしてみる。 zebedee localhost:smtp でクライアントを起動。
zebedee(4621/1024): Listening on local port 3401
と表示されたので telnet localhost 3401 で接続してみる。 成功。
ということで次は接続先のサーバ(FreeBSD)にインストール。 zebedee の make で OS=freebsd にするのと、ROOTDIRを $HOME/local/zebedee-2.2.1 にする以外は同じ。
で今度はローカルからFreeBSDサーバへ接続してみる。 FreeBSD 側で zebedee -s。 失敗。
zebedee(50819/5152): ERROR: can't resolve host or address 'localhost'
あちゃ。localhost でひけないか。 zebedee -s 実際のサーバ名 で起動する。
クライアント側から telnet で接続してみる。 zebedee 実際のサーバ名:telnet でクライアントを起動。
zebedee(8807/1024): Listening on local port 2324
と出たので telnet <i>実際のサーバ名</i> 2324 で telnet 接続。 成功。
やほ。成功。 問題は Zebedee サーバが落ちたときに telnet で入って起動しなおさなければならない事。 ま、しょうがないかなぁ。 cron まわして落ちていたら再起動するようにするかな……
次は pop の設定。 fetchmail で zebedee を利用するようにする。 fetchmail-with-zebedee.conf に
defaults
no mimedecode
pass8bits
poll popサーバ名
protocol pop3
via localhost
user ユーザ名
password パスワード
fetchall
と書いておき、
$zebedee -e "fetchmail -f fetchmail-with-zebedee.conf --port %d" popサーバ名:pop3
を実行。%d がトンネルのローカルポートに置換されて fetchmail が実行されるのでこれでトンネルを開いて pop する事ができる。 もちろん、ローカルポート番号を指定して Zebedee クライアントを起動しておいて、fetchmail の設定ファイルにそのポート番号を指定しておいても可能。
とりあえずこれである程度安心。 接続が横取りされているかチェックするには Identity Checking をしなければならない(し Zebedee はそれが可能だ)が、面倒になってくるのでそこまではいいにする。
2005年1月8日 (土)
NSIS が再び Linux でコンパイルできるように
2.01 で POSIX プラットフォームで動くようになった NSIS であるが、2.02、2.03 は Linux上ではソースパッケージからのビルドでエラーになってしまっていた。
1月5日に 2.04 がリリースされたので、こちらも試してみる。お、ビルドできた。
tar jxvf nsis204.tar.bz2 cd NSIS/Source make USE_PRECOMPILED_EXEHEADS=1 cd .. su ./install.sh /usr/local/NSIS-2.04
インストール時に Menu ディレクトリが無くてエラーメッセージが出るのは前回と一緒。CVS リポジトリをみるとHTMLで書かれたドキュメントがあるだけのようなので、無くても問題なさそうである。 付属の install.sh も改行コードが CRLF から LF に修正されているためそのまま実行できるようになった。
[ Linux 上で NSIS ]
2005年2月23日 (水)
ActivePerl で Ming
ActivePerl で Ming を使えるようにしておきたい。
Visual Studio で
Ming 0.3 beta1 のソースパッケージには Visual Studio 6.0 用のプロジェクトファイルが含まれている。 Cygwin の Bison と flex があればライブラリをビルドできるようだ。 横着して Linux 側で bison と flex で生成したファイルをコピーして(それから unistd.h をインクルードしている部分を消して)、ビルドしてみたところ一応 lib ファイルは作成成功。
しかし ActivePerl 用にPerl モジュールの make は失敗。
MinGW + nmake で ActivePerl のモジュールをビルドできるらしい
調べたところ ExtUtils::FakeConfig を使うと Visual Studio が無くても MinGW + nmake でモジュールをビルドできるらしい(全てではないと思うが)。
ということで Ming を MinGW でビルドした後、そのまま ActivePerl 用モジュールの作成まで持ち込むことにしてみる。
MinGW + MSYS + GnuWin32 で開発環境を構築
コンパイルに必要な環境を MinGW で、configure に必要な環境を MSYS で用意する。
bison は GnuWin32 で
Ming のビルドに必要な Bison は MinGW、MSYS のインストーラに含まれていない。 bison-1.875.0-2003.02.10-1.exe というのが別途あるがうまく動かない。
ソースパッケージ(bison-2.0.tar.gz、bison-1.875.tar.gz)からはビルドできず。 MinGW/MSYSのプロジェクトにある bison-1.875-2003.02.10-1-src.tar.gz はビルドできるものの make check が通らない。
とうことで GnuWin32 の bison-1.875-4.exe (インストーラ形式)をインストール。 c:/usr/local/GnuWin32 にインストールした後、MSYS の /etc/fstab で /GnuWin32 にマウントし、/GnuWin32/bin に PATH を通しておく。
flex はソースパッケージから
flex-2.5.4a.tar.gz を展開して
./configure; make; make check; make install
インストール時ハードリンクが作れなくてエラーがでているようだが無視。
zlib (Ming で必要)
MSYS 上でビルドしてインストール。zlib-1.2.2.tar.gz を展開して
./configure; make; make check; make install
LibUnGif for Windows (Ming で必要)
MSYS 上でビルドしてインストール。 libungif-4.1.0b1-src.zip を展開して
rm config.cache; config.h内の-DHAVE_VARARGS_Hをコメントアウト。 ./configure; make; make install
make check はエラーが出るが無視。
libpng (Ming で必要)
MSYS 上でビルドしてインストール。libpng-1.2.8-config.tar.gz を展開して
CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure make; make check; make install
いよいよ Ming
MSYS 上でビルド。ming-0.3beta1.tar.gz を展開して
CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib make static
ActivePerl 用モジュール作成
ExtUtils::FakeConfig と PPM::Make で Ming の SWF PPM パッケージを作成する。 (MSYSのシェルではなく)コマンド プロンプトを開いて、Mingソースパッケージの中の perl_ext に移動。 MSYS、MinGW、nmake にPATHを通しておく。
それから Makefile.PL の実行で -lz を発見できないので、libz.a を Makefile.PL と同じディレクトリにコピーしてしまう(-L/usr/local/lib を指定しても効かなかったので)。 libpng.a、libungif.a も同じくコピーしておく。
Makefile を作成。Makefile.PL では -lz しか指定していないが、libpng と libungif も必要なのでコマンドラインオプションで指定する。ExtUtils::FakeConfig の Config_m を使用して MinGW を使用するようにする。
perl -MConfig_m Makefile.PL LIBS="-lpng -lungif -lz"
ここで生成される Makefile の中で libperl58.a を指定している部分があるが、ActivePerl では perl58.lib になるので、エディタで書き換え。 後はいつも通り
nmake nmake test make_ppm
で PPM パッケージ作成完了。
2005年4月20日 (水)
SCons は GNU Autotools のかわりになるか
NSIS のサイトによるとビルドに「SCons」を使うようしたらしい。
と興味深いツールになっているようだ。
現在プロジェクトLaTeXベースのドキュメント生成には GNU Make を使っているのだが、UNIX、Windows の両方でビルドできるようにするには ComSpec 環境変数の有無で使用するコマンドを切り換えたり等いろいろ面倒なので、代替ツールとして使えないかなと。
基本的な機能は Make に対する改良がなされているようであるし、コピー等ファイル操作も SCons 自体がもっているのでクロスプラットフォームでビルドできるようにするのも楽そうだ。
一方 Autoconf 系の機能については、インストール済みのライブラリの検出や実装レベルのチェック等を実装しているようである。 make check や make dist、make install 等にあたるターゲットに関する機能(あるいは規約)のようなものは無い。これは非常に残念。 結局自分が Ant を使わなくなったのも GNU Autotools にあるこれらの機能に欠けているからであるし。
実は私がPerl が好きな理由の一つとして、これらサポートが充実しているという点がある。Perl では ExtUtils::MakeMaker (あるいは Module::Build)があり、ビルドからテスト、ソースパッケージのパッケージングまでフレームワークが整っている。
SCons は Python ベースで、Makefile にあたるファイルも Python スクリプトである。 SCons が影響を受けた Cons は Perl ベースであったのだが、既に2001年5月ごろから開発が止まってしまっている。残念。
ということで Make の代替には使えそうであるが、GNU Autotools と同じようなことをするにはいろいろ手をかけないといけないといった印象。
2005年8月24日 (水)
Module::Build でソースパッケージング
ExtUtils::MakeMaker
私が Perl が好きな理由の一つに、標準でExtUtils::MakeMakerという Makefile ジェネレータがついているところである。これを使って Makefile.PL を書くと
perl Makefile.PL make manifest make make test make dist
で <pacakge>-<versionno>.tar.gz というソースパッケージを作ることができ、
tar zxvf <pacakge>-<versionno>.tar.gz cd <pacakge>-<versionno> perl Makefile.PL make make test make install
という手順でインストールする事ができるようになる。 パッケージの作り方が確立されているので、容易に新しいパッケージを開発しはじめられる。
逆に Java でプログラムを書くのが億劫なのは、このあたりの準備が面倒だからである。 Ant を使っても結局ここら辺自分でやらなければならないし。
ちょっとしたアーカイブの作成
ちょっとしたパッケージを作りたいと思うことは良くある。 例えばいくつかのデータファイルと、READMEファイルなんかをひとまとめにしてアーカイブにするとか。
本当にちょっとしたであれば、手動でアーカイブすれば良いのだが、
- アーカイブしたいファイル群がバージョン管理下にあって、CVS ディレクトリや .svn ディレクトリがある (除外してアーカイブする必要がある)
- 同じディレクトリにある、作業用のファイルはアーカイブしたくない (除外してアーカイブする必要がある)
- アーカイブする前に、チェック用のリグレッションテスト一式を走らせたい (リグレッションテストをかけられるようにする)
- UNIX でも Windows でもアーカイブ化できるようにしたい。
あたりを考慮しなければならない時は面倒くさくなってくる。
自動化としては
- シェルスクリプト/バッチファイルを書く
- Makefile を書く
- GNU Autotools を使う
あたりがぱっと思い浮かぶ。 しかし、最初の2つは毎回同じようなものを書くのが面倒だし保守もしにくい。 GNU Autotools はちょっとごっつすぎだし、Windows での環境構築も面倒。
ExtUtils::MakeMaker の欠点
ということで最初は ExtUtils::MakeMaker を使うという線で考えてみた。 もともと Perl モジュール用で汎用用途にはちょっと邪魔な振舞いもあるが、使えないことはないと思う。 しかし make (GNU Make あるいは nmake など) に依存しているという欠点がある。
Module::Build で
ということで ExtUtils::MakeMaker の代替である Module::Build ベースで汎用用途に使えないか検討してみた。こちらは pure Perl で make を必要としない。
Module::Build も Perl モジュールビルドにあわせた振舞いがあるものの、ちょっとカスタマイズすれば使えそうだ。 で、いろいろいじった結果、次のような感じにすると使いやすそうだ。
use Module::Build;
my $class = Module::Build
->subclass(class => 'NonmoduleBuilder',
code => q{
# Don't make blib
sub ACTION_code {};
# Don't make blib
sub ACTION_docs {};
# Don't make META.yml
sub ACTION_distmeta {
# no warning on ACTION_distdir
$_[0]->{metafile} = 'MANIFEST';
};
# Don't add MEATA.yml to MANIFEST
sub ACTION_manifest {
$_[0]->{metafile} = 'MANIFEST',
$_[0]->SUPER::ACTION_manifest(@_);
};
});
# Set your archive name and version.
$class->new(dist_name => 'mypackage',
dist_version => '1.0.2',
)->create_build_script;
カスタマイズした部分は以下(Module::Build 0.26 で動作確認)。
- Perl モジュールビルドに特有の blib ディレクトリを作らないようにする。
- META.yml を生成しないようにし、アーカイブに含まれないようにする。
上記のようなファイルを Build.PL という名前で作っておけば
perl Build.PL ./Build manifest ./Build ./Build test ./Build dist
等として、アーカイブ作成が容易にできるようになる。
しばらくこの方法でいろいろ試してみることにしてみよう。
2006年2月12日 (日)
野良パッケージと依存 Perl モジュールのインストールセット を CPAN::Mini::Inject で
前回は CPAN::Site を用いたオフライン用インストールセットを作成した。
今回は空の CPAN のミラーを作り、そこに野良パッケージを突っ込んで使用する形でインストールセットを作成してみる。
~/perl-5.8.8 以下にクリーンな Perl 5.8.8 をインストールしてインストールセットを作成していく。
CPAN::Mini::Inject をインストールする (オンライン)
perl -MCPAN -e shell cpan> install CPAN::Mini::Inject cpan> exit
CPAN::Mini::Inject は、インストールセットには必要ない。 ~/perl-5.8.8 にはインストールせずに、普段使っているほうにインストールしておく。
インストールしたい野良パッケージ用のローカル CPAN サーバを作成する (オンライン)
以下スクリプト例(エラー処理などは省略)
#!/usr/bin/perl -w
use strict;
use File::Path;
use CPAN::Mini;
use CPAN::Mini::Inject;
my $remote = 'ftp://ftp.dti.ad.jp/pub/lang/CPAN/';
my $local = '/home/myname/public_html/CPAN';
my $repository = '/home/myname/repository';
mkpath([$local, $repository], 1, 0755);
# module_filters で全てのモジュールを対象外にして、空の CPAN ミラーを作る
CPAN::Mini->update_mirror(remote => $remote,
local => $local,
diremode => 0755,
trace => 1,
module_filters => [ qr/./ ]);
my $injector = CPAN::Mini::Inject->new;
$injector->{config}{remote} = $remote;
$injector->{config}{local} = $local;
$injector->{config}{repository} = $repository;
$injector->{config}{diremode} = 0755;
# CPAN::Mini::Inject リポジトリに追加したあと、
# CPAN ミラーへ 注入
$injector->add(repository => $repository,
module => 'WiKicker',
authorid => 'NANEY',
version => '0.xx',
file => 'WiKicker-0.xx.tar.gz')
->inject;
これで、~/public_html/CPAN に野良パッケージの追加された CPAN ミラーが作成される。
WiKicker と依存するモジュールをインストールする (オンライン)
rm -rf ~/.cpan ~/perl-5.8.8/bin/perl -MCPAN -e shell cpan> o conf urllist pop cpan> o conf urllist push http://http://localhost/CPAN cpan> reload index cpan> o conf urllist push ftp://ftp.dti.ad.jp/pub/lang/CPAN/ cpan> install WiKicker cpan> exit
ここでローカル CPAN サーバを file:/// 等で指定すると、そこから読みとったファイルは ~/.cpan/sources/ 以下にコピーされないので一箇所にまとめることができないので注意。
またCPAN ではモジュールインデックスファイルは1組しか持てないようで、初期設定のままだと野良パッケージを含む CPAN ミラーのインデックスファイルが使われない。 そのため一旦 urllist を空にした後、 自分の CPAN ミラーを指定しインデックスファイルをロードする。 その後にソースパッケージを取得するセカンダリとして通常の CPAN (ミラー)を指定するようにしている。
これが終わると、WiKicker とそれに必要なファイルが ~/.cpan/sources にたまる。
これを適宜アーカイブして保存する。
オフラインでインストールする
別の環境で例えば /usr/local/perl-5.8.8 にインストールされた Perl に WiKicker をオフラインでインストールするとする。
先の工程で作成したファイルセットが /tmp/CPAN においてあるものとする。
/usr/local/perl-5.8.8/bin/perl -MCPAN -e shell # 初期化でオフラインのため CPAN ミラーの選択ができずに URL の入力を # 求められたところで file:///tmp/CPAN を指定 cpan> install WiKicker cpan> exit
これで /tmp/CPAN から芋蔓式に WiKicker がインストールされる。
ポイント
CPAN::Site を利用して構築した場合は、インストール時にも CPAN::Site が必要だが、こちらはインストールセットの利用には CPAN.pm だけで良いというのが利点。
今回は CPAN::Mini で空の CPAN ミラーを作成し野良パッケージを追加した。
ここで最初から CPAN の最新パッケージの全ミラーを CPAN::Mini で作成し、これに野良パッケージを追加してインストールセットを作ってしまうという方法もある。 この場合は後で必要に応じてミラーからパッケージを入れられるというメリットがあるかわりに、ミラー作成のコストがかかるというデメリットがある。
2006年4月15日 (土)
sid の CinePaint がプラグイン読み込みでエラー
10枚の「ゴッサム・シティ東京 」を見て HDR イメージに興味を持った。
で早速日中に、手持ちのデジカメで段階露出をした写真を取りためて、家に帰って HDRI 作成に入る。 Linux だと CinePaint あたりが王道か。 CinePaint 0.21 には
- "Bracketing to HDR" Plugin for CinePaint (Version 0.4.1)
が最初から入っており、段階露出で撮影したデジタル画像から HDR イメージを作成できるのである。
が。
Debian GNU/Linux sid で cinepaint 0.21-1 をインストールして起動してみると、
/usr/lib/cinepaint/0.20-1/plug-ins/bracketing_to_hdr: symbol lookup error: /usr/lib/libcinepaint.so.0: undefined symbol: gtk_marshal_NONE__NONE wire_read: unexpected EOF (plug-in crashed?)
と出てしまうではないが。CinePaint 自体は起動するのだが、プラグインが読みこみ失敗してしまっているようだ。全てのプラグインの読み込みに失敗している様子である。
環境依存かと思いソースパッケージからビルドし直してみてもやっぱり同様。
そんな。
2006年12月20日 (水)
NSIS 2.22 は Linux でビルドできず
Windows 用のインストーラ作成ツール NSIS は、スクリプトベースでインストーラを作っていくのが1つの特徴である。 NSIS スクリプトは、さすがインスーラ作成用だけあって
- ファイル処理 (コピー、削除、……)
- レジストリの読み書き
- プログラムの実行
その他システム関連のコマンドが充実している。 コンパイルするとかなりコンパクトな実行形式ファイル (EXE) を生成してくれるので、ちょっとした処理を自動化するには便利である。
今回 USB メモリに入れておいて、そのドライブ上のいくつかのディレクトリに PATH が通った状態でコマンドプロンプトを開くツールを NSIS で書いておこうかと思って試す。
NSIS は POSIX ベースシステムでビルドし実行でき、NSIS スクリプトをコンパイルできる。 ということで作業を Linux で作業をしていたのだが、どうやら System::Call が使えないようだ(スクリプトのコンパイルに失敗する)。
Debian パッケージが古いせい (2.19-1.1) かと思い、ソースパッケージをビルドしてみたらまさに System 関連らしいところでコンパイルがこけている (そういう背景で Debian パッケージがアップデートされていない?)。
ということでどうも最新の NSIS は Linux では駄目っぽい。
しょうがないので久しぶりに Wine。
Wine 上に NSIS 2.22 をインストールして makensis.exe を実行してみたところ試した範囲ではうまく動いている。 ついでにでき上がった実行可能ファイルも Wine 上で試せる。
しばらくは Wine 上で NSIS スクリプト書きを楽しむことにしよう (最終的には Windows 上でコンパイルしなおして動作確認するのだけれども)。
2007年7月31日 (火)
Windows 向けソフトウェア開発者はソースパッケージを作る習慣がない
GNU Autotools や ExtUtils::MakeMaker (とその仲間たち)で make dist するのがあたり前になっている自分には、気持ち悪い。
About
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。