""エラーになった場合はopensslの再ビルドを行う。RAILS_ENV="production"メールの送信設定を行う不要と思われる。libcurl4-openssl-devnginxの再ビルド(ないしソースコード)が必要になるので、すでにapt-getしたnginxがある場合には使えない。その場合はpassengerをstandaloneで起動して、そこに対してnginxからproxy-passなりなんなりする。以下、passengerスタンドアロンで起動し、redmineはすべてpassengerにやらせる場合を考えます。passengerのスタンドアロンは内部的にはnginxを使っているので、いずれにせよ上記のインストールは必要になります。■得られたサポートhttp://redmine.jp/guide/RedmineInstall/■顧客が本当に必要だったものhttp://twitter.com/shin_no_suke/status/35632371084562433http://twitter.com/hirokinko/status/36307730025156608http://twitter.com/hirokinko/status/36310634127695872■元ネタhttp://ryonoda.wordpress.com/2008/09/26/■一応補足Redmine自体はすごく良いアプリだと思います。いま使ってますが、とっても助かってます。bitnamiの配布しているパッケージが対話環境でもインストールできるというのは知りませんでした。textでうまくいくようです。Subversionをインストールされてしまうみたいなので、きちんと管理したいとなるとちょっと不向きかなと。いう変態の巣窟に来ています。ハンズオンを受けているのですが、いくつか詰まった点があったのでメモ。■virtualenv普通にインストールするとき(ベースとなるpythonのsite-packageを受け継がないようにする場合)は以下のようにします。2.6.1ではエラーになってしまいました。myenvのようにして-pオプションを使いベースとなるPythonのパスを明示的に指定することで上手い具合にインストールできました。2.6.1のsetuptoolsはバージョンが低い(0.6c9)ため、以下のようなエラーが出てしまうことがあります。(/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python))もちろんsetuptoolsのバージョンを上げてもいいのですが、あまりデフォルトの環境を汚したくありません。そこで--distributeオプションを使用します。--distributeこうすると、distributeというsetuptools上位互換のモジュールが自動的にbuildout環境下にインストールされ、その結果上手い具合にインストールに成功します。buildout環境下へのインストールなのでデフォルトの環境は汚れません。Library)をインストールしようとして見事にハマりましたので、後学のために事の顛末を記しておきます。2.6.1を使用すること。2.5.4も付属しているが、こちらは使用するべきではない。2009年9月8日現在での断片的な情報です。皆様がごらんになっている時点では既にMacPort上のPythonやMacPythonも対応を完了しているかもしれませんので、参考程度にご覧ください。2.5.4はほんとお勧めしません。Leopardにアップグレードしたとたん突然PILモジュールがないと警告を出すようになってしまいました。確認してみると/Library/Python/Python2.5/site-packages/以下に確かにインストールされているのですが、何度試しても警告が消えません。これは何かがおかしい、再インストールした方がいいだろうと判断し、http://www.pythonware.com/products/pil/から1.1.6のソースコードを落としてきていざビルド。selftest.py・・・が、動きません。なにやらImagingMathが見つからないだのなんだのとエラーが出てしまいます。これだけではよく分からないので、直接PILのモジュールをPythonからimportしてみることにしました。/Library/Python/2.5/site-packages/PIL/_imaging.so>>>ふむふむ、どうやらこの_imaging.soというのがなにやら悪さをしているようです。@tokibito先生にお尋ねしたところ、このsoファイルというのはC言語のソースをコンパイルしたライブラリで、Pythonから動的にインポートできるようにpython.hというヘッダをインクルードしてつくられているらしいということが分かりました。それでPythonから直接C言語で書かれてビルドされたライブラリをimportできるんですね。なると怪しいのはPILのビルド工程。先ほどのエラーを見ると_jpeg_resync_to_restartというシンボルが見つからないと表示されていたため、インストールに使ったlibjpeg(MacPortよりインストール)に何か問題があったのではないかと推測したのですが、特に問題は見つからず。次にPILのビルドログを調査。細かいwarningが出まくるのはいつものことなので無視して調べてみますが、一見何もエラーは出ていません。するとあることに気づきました。build/lib.macosx-10.6-i386-2.5/_imaging.soうん、なるほど、原因が分かりました。ppcでしかビルドされていないのがまずそうですね。x86_64を追加してビルドしなければならないはずです。2.6.1でこの_imaging.soを読み込もうとしてみた結果がこちら。mode)>>>ビンゴ!間違いなさそうです!あとは、どうすれば64bitでビルド出来るかを調べるだけです。installコマンドがgccビルドを実行しているのかが分かりません。setup.pyのソースを読んでみることにしました。するとdistutils.command.build_extなるモジュールをimportして使っていることが判明。Python2.5のシステムライブラリをあさってみると、ありましたありました。depends=ext.depends)おおっといきなり発見、self.compiler.compileとか怪しさ抜群です。こいつはどこからやってきたのかとソースをたどると、なにやらunixccompiler.pyというモジュールを発見。私がコンパイラだと言わんばかり。犯人はこいつに違いない。コードを開いて-archとかで検索をかけてみましたが、i386とかppcとか直接指定している箇所は見あたりませんでした。その代わり別の収穫を発見。os.environ['ARCHFLAGS'].split()----後略----環境変数ARCHFLAGSとかいうのを見てるみたいです。x86_64"とか追加すればきちんと64bitビルドしてくれるのでしょうか?■そしてあっけない幕切れここまでなんとか一人で調査していたものの、たまりかねた隣の席の皆さんからアドバイス。2.6じゃないのがまずいんじゃね?」え、何、そういうこと?まぁ念のために試してみるか、ということでPythonを2.6に切り替えて再度PILをビルド。x86_64がビルドオプションについてる。selftest.py一発で通った。SDKがPILの警告吐かなくなった。