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 はそれが可能だ)が、面倒になってくるのでそこまではいいにする。

スポンサード リンク
[ 5月8日全て ]

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 ]

[ 1月8日全て ]

2005年2月23日 (水)

ActivePerlMing

ActivePerlMing を使えるようにしておきたい。

Visual Studio

Ming 0.3 beta1 のソースパッケージには Visual Studio 6.0 用のプロジェクトファイルが含まれている。 Cygwin の Bison と flex があればライブラリをビルドできるようだ。 横着して Linux 側で bison と flex で生成したファイルをコピーして(それから unistd.h をインクルードしている部分を消して)、ビルドしてみたところ一応 lib ファイルは作成成功。

しかし ActivePerl 用にPerl モジュールの make は失敗。

MinGW + nmakeActivePerl のモジュールをビルドできるらしい

調べたところ ExtUtils::FakeConfig を使うと Visual Studio が無くても MinGW + nmake でモジュールをビルドできるらしい(全てではないと思うが)。

ということで MingMinGWビルドした後、そのまま ActivePerl 用モジュールの作成まで持ち込むことにしてみる。

MinGW + MSYS + GnuWin32開発環境を構築

コンパイルに必要な環境を MinGW で、configure に必要な環境を MSYS で用意する。

bison は GnuWin32

Mingビルドに必要な Bison は MinGWMSYSインストーラに含まれていない。 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::FakeConfigPPM::MakeMingSWF PPM パッケージを作成する。 (MSYSシェルではなく)コマンド プロンプトを開いて、Mingソースパッケージの中の perl_ext に移動。 MSYSMinGWnmake に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 パッケージ作成完了。

簡単なPerlプログラムでSWFファイルが作れる事を確認。 やった。

[ 2月23日全て ]

2005年4月20日 (水)

SConsGNU Autotools のかわりになるか

NSIS のサイトによるとビルドに「SCons」を使うようしたらしい。

  • クロスプラットフォーム
  • AutoconfAutomake と同様の機能を統合
  • LaTeX もビルトインサポート

と興味深いツールになっているようだ。

現在プロジェクトLaTeXベースのドキュメント生成には GNU Make を使っているのだが、UNIXWindows の両方でビルドできるようにするには ComSpec 環境変数の有無で使用するコマンドを切り換えたり等いろいろ面倒なので、代替ツールとして使えないかなと。

基本的な機能は Make に対する改良がなされているようであるし、コピー等ファイル操作も SCons 自体がもっているのでクロスプラットフォームでビルドできるようにするのも楽そうだ。

一方 Autoconf 系の機能については、インストール済みのライブラリの検出や実装レベルのチェック等を実装しているようである。 make check や make dist、make install 等にあたるターゲットに関する機能(あるいは規約)のようなものは無い。これは非常に残念。 結局自分が Ant を使わなくなったのも GNU Autotools にあるこれらの機能に欠けているからであるし。

実は私がPerl が好きな理由の一つとして、これらサポートが充実しているという点がある。Perl では ExtUtils::MakeMaker (あるいは Module::Build)があり、ビルドからテスト、ソースパッケージのパッケージングまでフレームワークが整っている。

SConsPython ベースで、Makefile にあたるファイルも Python スクリプトである。 SCons が影響を受けた Cons は Perl ベースであったのだが、既に2001年5月ごろから開発が止まってしまっている。残念。

ということで Make の代替には使えそうであるが、GNU Autotools と同じようなことをするにはいろいろ手をかけないといけないといった印象。

[ 4月20日全て ]

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 でもアーカイブ化できるようにしたい。

あたりを考慮しなければならない時は面倒くさくなってくる。

自動化としては

あたりがぱっと思い浮かぶ。 しかし、最初の2つは毎回同じようなものを書くのが面倒だし保守もしにくい。 GNU Autotools はちょっとごっつすぎだし、Windows での環境構築も面倒。

ExtUtils::MakeMaker の欠点

ということで最初は ExtUtils::MakeMaker を使うという線で考えてみた。 もともと Perl モジュール用で汎用用途にはちょっと邪魔な振舞いもあるが、使えないことはないと思う。 しかし make (GNU Make あるいは nmake など) に依存しているという欠点がある。

Module::Build

ということで ExtUtils::MakeMaker の代替である Module::Build ベースで汎用用途に使えないか検討してみた。こちらは pure Perl で make を必要としない。

Module::BuildPerl モジュールビルドにあわせた振舞いがあるものの、ちょっとカスタマイズすれば使えそうだ。 で、いろいろいじった結果、次のような感じにすると使いやすそうだ。

 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

等として、アーカイブ作成が容易にできるようになる。

しばらくこの方法でいろいろ試してみることにしてみよう。

[ 8月24日全て ]

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 にインストールされた PerlWiKickerオフラインインストールするとする。

先の工程で作成したファイルセットが /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 で作成し、これに野良パッケージを追加してインストールセットを作ってしまうという方法もある。 この場合は後で必要に応じてミラーからパッケージを入れられるというメリットがあるかわりに、ミラー作成のコストがかかるというデメリットがある。

[ 2月12日全て ]

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 自体は起動するのだが、プラグインが読みこみ失敗してしまっているようだ。全てのプラグインの読み込みに失敗している様子である。

環境依存かと思いソースパッケージからビルドし直してみてもやっぱり同様。

そんな。

[ 4月15日全て ]

2006年12月20日 (水)

NSIS 2.22 は Linuxビルドできず

Windows 用のインストーラ作成ツール NSIS は、スクリプトベースでインストーラを作っていくのが1つの特徴である。 NSIS スクリプトは、さすがインスーラ作成用だけあって

  • ファイル処理 (コピー、削除、……)
  • レジストリの読み書き
  • プログラムの実行

その他システム関連のコマンドが充実している。 コンパイルするとかなりコンパクトな実行形式ファイル (EXE) を生成してくれるので、ちょっとした処理を自動化するには便利である。

今回 USB メモリに入れておいて、そのドライブ上のいくつかのディレクトリに PATH が通った状態でコマンドプロンプトを開くツールを NSIS で書いておこうかと思って試す。

NSISPOSIX ベースシステムでビルドし実行でき、NSIS スクリプトをコンパイルできる。 ということで作業を Linux で作業をしていたのだが、どうやら System::Call が使えないようだ(スクリプトのコンパイルに失敗する)。

Debian パッケージが古いせい (2.19-1.1) かと思い、ソースパッケージビルドしてみたらまさに System 関連らしいところでコンパイルがこけている (そういう背景で Debian パッケージアップデートされていない?)。

ということでどうも最新の NSISLinux では駄目っぽい。

しょうがないので久しぶりに Wine

Wine 上に NSIS 2.22 をインストールして makensis.exe を実行してみたところ試した範囲ではうまく動いている。 ついでにでき上がった実行可能ファイルWine 上で試せる。

しばらくは Wine 上で NSIS スクリプト書きを楽しむことにしよう (最終的には Windows 上でコンパイルしなおして動作確認するのだけれども)。

[ 12月20日全て ]

2007年7月31日 (火)

Windows 向けソフトウェア開発者はソースパッケージを作る習慣がない

GNU AutotoolsExtUtils::MakeMaker (とその仲間たち)で make dist するのがあたり前になっている自分には、気持ち悪い。

ビルドの自動化とソースパッケージ作成の自動化・バージョン管理のセットアップは、最初の仕事だと思うのだが。

[ 7月31日全て ]

2008年7月19日 (土)

今日のさえずり: デックス東京ビーチモンベルなくなってたか

2008年07月19日

[ 7月19日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

follow us in feedly

月別インデックス
Process Time: 0.05917s / load averages: 0.37, 0.29, 0.26
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker